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It's fair to say that MySQL is the most popular open source database.It 
has a very large installed base and number of users.Let's see what are the 
reasons MySQL is so popular,where it stands currently,and maybe touch on 
some of its future(although predicting the future is rarely successful). 


Looking at the customer area of MySQL,which includes 
Facebook,Flickr, Adobe(in Creative Suite 
3),Drupal,Digg, LinkedIn, Wikipedia,eBay, YouTube,Google AdSense(source 
http://mysql.com/customers/and public resources),it's obvious that MySQL is 
everywhere.When you log in to your popular forum(powered by Bulleting)or 
blog(powered by WordPress),most likely it has MySQL as its backend 
database.Traditionally,two MySQL's characteristics,simplicity of use and 
performance,were what allowed it to gain such popularity.In addition to 
that,availability on a very wide range of platforms(including Windows)and 
built-in replication,which provides an easy scale-out solution for read-only 
clients,gave more user attractions and production deployments.There is 
simple evidence of MySQL's simplicity:In 15 minutes or less,you really can 
get installed,have a working database,and start running queries and store 
data.From its early stages MySQL had a good interface to most popular 
languages for Web development-PHP and Perl,and also Java and ODBC 
connectors. 


There are two best known storage engines in MySQL:MyISAM and 
InnoDB(I don't cover NDB cluster here;it's a totally different story). MyISAM 
comes as the default storage engine and historically it is the oldest,but 
InnoDB is ACID compliant and provides  transactions,row-level 
locking, MVCC,automatic recovery and data corruption detection.This makes 
it the storage engine you want to choose for your application.Also,there is the 
third-party transaction storage engine PBXT,with characteristics similar to 
InnoDB,which is included in the MariaDB distribution. 


MySQL's simplicity has its own drawback.Just as it is very easy to start 
working with it,it is very easy to start getting into trouble with it. As soon as 
your website or forum gets popular,you may figure out that the database is a 


bottleneck,and that you need special skills and tools to fix it. 


The author of this book is a MySQL expert,especially in InnoDB storage 
engineB.Hence,I highly recommend this book to new users of InnoDB as 
well as uers who already have well-tuned InnoDB-based applications but 
need to get internal out of them. 


Vadim Tkachenko 

全 球 知名 MySQL 数 据 库 服务 提供 商 Percona 公 司 CTO 
知名 MySQL 数 据 库 博客 MySQLPerformanceBlog.com 作 者 
《高 性 能 MySQL “第 2 版 ，》 作 者 之 一 
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过 去 这 些 年 我 一 直 在 和 各 种 不 同 的 数据 库 打 交道 ， 见 证 了 MySQL 
从 一 个 小 型 的 关系 型 数据 库 发 展 为 各 大 企业 的 核心 数据 库 系 统 的 过 程 ， 
并 且 参 与 了 一 些 大 大 小 小 的 项 目的 开发 工作 ， 成 功 地 帮助 开发 人 员 构建 
了 可 靠 的 、 健 壮 的 应 用 程序 。 在 这 个 过 程 中 积累 了 一 些 经 验 ， 正 是 这 些 
不 断 累 积 的 经 验 赋予 了 我 灵感 ， 于 是 有 了 这 本 书 。 这 本 书 实际 上 反映 了 
这 些 年 来 我 做 了 哪些 事情 ， 其 中 汇集 了 很 多 同行 每 天 可 能 都 会 过 到 的 一 
些 问 题 ， 并 给 出 了 解决 方案 。 


MySQL 数 据 库 独 有 的 插件 式 存储 引擎 架构 使 其 和 其 他 任何 数据 库 
都 不 同 。 不 同 的 存储 引擎 有 着 完 全 不 同 的 功能 ， 而 InnoDB 存 储 引 擎 的 
存在 使 得 MySQL 跃 入 了 企业 级 数据 库 领 域 。 本 书 完整 地 讲解 了 InnoDB 
存储 引擎 中 最 重要 的 一 些 内 容 ， 即 InnoDB 的 体系 结构 和 工作 原理 ， 并 
结合 InnoDB 的 源 代码 讲解 了 它 的 内 部 实现 机 制 。 


本 书 不 仅 讲 述 了 InnoDB 存 储 引 擎 的 诸多 功能 和 特性 ， 还 前 述 了 如 
何 正确 地 使 用 这 些 功 能 和 特性 ， 更 重要 的 是 ， 还 尝试 了 教 我 们 如 何 
Think Different. Think Different 是 20 世 纪 90 年 代 苹 果 公 司 在 其 旷日持久 
的 宣传 活动 中 提出 的 一 个 口号 ， 借 此 来 重 振 公 司 的 品牌 ， 更 重要 的 是 ， 
这 个 口号 改变 了 人 们 对 技术 在 日 利生 活 中 的 作用 的 看 法 。 需 要 注意 的 
是 ， 苹 果 的 口号 不 是 Think Differently， 是 Think Different，Different 在 这 
里 做 名 词 ， 意 味 该 思考 些 什么 。 


很 多 DBA 和 开发 人 员 都 相信 某 些 “神话 ”， 然 而 这 些 “ 神 话 ” 往 往 都 是 
普 误 的 。 无 论 计算 机 技术 发 展 的 速度 变 得 多 快 ， 数 据 库 的 使 用 变 得 多 么 
简单 ， 任 何 时 候 Why 都 比 What 重 要 。 只 有 真正 理解 了 内 部 实现 原理 、 体 
系 结构 ， 才 能 更 好 地 去 使 用 。 这 正 是 人 类 正确 思考 问题 的 原则 。 因 此 ， 
对 于 当前 出 现 的 技术 ， 尽 管 学 习 其 应 用 很 重要 ， 但 更 重要 的 是 ， 应 当 正 
确 地 理解 和 使 用 这 些 技术 。 


关于 本 书 ， 我 的 头脑 里 有 很 多 个 目标 ， 但 最 重要 的 古 想 告 诉 大 家 如 
下 几 个 简单 的 观点 : 















































口 不 要 相信 任何 的 “神话 >， 学 会 目 己 思考 ; 

口 不 要 墨守成规 ， 大 部 分 人 都 知道 的 事情 可 能 古 错误 的 ; 
口 不 要 相信 网 上 的 传言 ， 去 测试 ， 根 据 自 己 的 实践 做 出 决定 ; 
口 花 时 间 充 分 地 思考 ， 敢 于 提出 质疑 。 


当前 有 关 MySQL 的 书籍 大 部 分 都 集中 在 教 访 者 如 何 使 用 MYSQL， 
例如 SQL 语句 的 使 用 、 复 制 的 搭建 的 、 数 据 的 切 分 等 。 没 错 ， 这 对 快速 
掌握 和 使 用 MYSQL 数据 库 非 常 有 好 处 ， 但 是 真正 的 数据 库 工 作者 需要 
了 解 的 不 仅仅 是 应 用 ， 更 多 的 是 内 部 的 具体 实现 。 


MySQL 数 据 库 独 有 的 插件 式 存储 引擎 使 得 想 要 在 一 本 书 内 完整 地 
讲解 各 个 存储 引 苟 变 得 十 分 困难 ， 有 的 书 可 能 偏 备 对 MyISAM 的 介绍 ， 
有 的 可 能 偏重 对 InnoDB 存 储 引 擎 的 介绍 。 对 于 初级 的 DBA 来 说 ， 这 可 
能 会 使 他 们 的 理解 变 得 更 困难 。 对 于 大 多 数 MySQL DBA 和 开发 人 员 来 
说 ， 他 们 往往 更 希望 了 解 作 为 MySQL 企 业 级 数据 库 应 用 的 第 一 存储 引 
擎 的 mnoDB， 我 想 在 本 书 中 ， 他 们 完全 可 以 找到 他 们 希望 了 解 的 内 
A. 














再 强调 一 遍 ， 任 何 时 候 Why 都 比 What 重 要 ， 本 书 从 源 代 码 的 角度 对 
InnoDB 的 存储 引擎 的 整个 体系 架构 的 各 个 组 成 部 分 进行 了 系统 的 分 析 
和 讲解 ， 训 析 了 InnoDB 存 储 引 擎 的 核心 实现 和 工作 机 制 ， 相 信 这 在 其 
他 书 中 是 很 难 找到 的 。 


第 1 版 与 第 2 版 的 区 别 


本 书 是 第 2 版 ， 在 写作 中 吸收 了 读者 对 上 一 版 内 容 的 许多 意见 和 建 
议 ， 同 时 对 于 最 新 MySQL 5.6 中 许多 关于 InnoDB 存 储 引 擎 的 部 分 进行 了 
详细 的 解析 与 介绍 。 和 希望 通过 这 些 改进 ， 给 读者 一 个 从 应 用 到 设计 再 到 
实现 的 完整 理解 ， 弥 补 上 一 版 中 深度 有 余 ， 内 容 层 次 不 够 丰富 、 分 析 手 
法 单一 等 诸多 不 足 。 


较 第 1 版 而 言 ， 第 2 版 的 改动 非常 大 ， 基 本 上 重 写 了 50% 的 内 容 。 其 
主要 体现 在 以 下 几 个 方面 ， 和 希望 读者 能 够 在 阅读 中 体会 到 。 


口 本 书 增加 了 对 最 新 MySQL 5.6 中 的 InnoDB 存 储 引 擎 特性 的 介绍 。 
MySQL 5.6 版 本 是 有 史 以 来 最 大 的 一 次 更 新 ，InnoDB 存 储 引 擎 更 是 添加 
了 许多 功能 ， 如 多 线程 清理 线程 、 全 文 索引 、 在 线索 引 添加 、 独 立 回 滚 
段 、 非 递归 死 锁 检测 、 新 的 刷新 算法 、 新 的 元 数据 表 等 。 读 者 通过 本 书 
可 以 知道 如 何 使 用 这 些 特性 、 新 特性 存在 的 局 限 性 ， 并 明白 新 功能 与 老 
版 本 InnoDB 存 储 引 擎 之 间 实 现 的 区 别 ， 从 而 在 实际 应 用 中 充分 利用 这 


些 特性 。 


口 根据 读者 的 要 求 对 于 InnoDB 存 储 引 擎 的 redo 日 志和 undo 日 志 进 行 
了 详细 的 分 析 。 读 者 应 该 能 更 好 地 理解 InnoDB 存 储 引 擎 事务 的 实现 。 
在 undo 日 志 分 析 中 ， 通 过 InnoSQL 目 带 的 元 数据 表 ， 用 户 终 于 可 对 undo 
E 志 进 行 统计 和 分 析 ， 极 大 提高 了 DBA 对 于 InnoDB 存 储 引 擎 内 部 的 认 
Ho 


口 对 第 6 章 进 行 大 幅度 的 重 写 ， 恋 者 可 以 更 好 地 理解 InnoDB 存 储 引 
擎 特有 的 next-key _ locking 算法， 并 且 通 过 分 析 锁 的 实现 来 了 解 死 锁 可 能 
x S 以 及 InnoDB 存 储 引 擎 内 部 是 如 何 来 避免 死 锁 问 题 的 产生 
um 

















口 根 据 读者 的 反 饿 ， 对 InnoDB 存 储 引擎 的 insert buffer 模 块 实现 进行 
了 更 为 详细 的 介绍 ， 读 者 可 以 了 解 其 使 用 方法 以 及 其 内 部 的 实现 原理 。 
此 外 还 增加 了 对 insert buffer 的 升级 版 本 功能 change buffer 的 介绍 。 





读者 对 象 


本 书 不 是 一 本 面向 应 用 的 数据 库 类 书籍 ， 也 不 是 一 本 参考 手册 ， 更 
不 会 教 你 如 何在 MySQL 中 使 用 SQL 语句 。 本 书面 向 那些 使 用 MySQL 
InnoDB 存 储 引 擎 作为 数据 库 后 端 开 发 应 用 程序 的 开发 者 和 有 一 定 经 验 
的 MySQL ”DBA。 书 中 的 大 部 分 例子 都 是 用 SQL 语 句 来 展示 关键 特性 
的 ， 如 果 想 通过 本 书 来 了 解 如 何 局 动 MySQL、 如 何 配 置 Replication 环 
境 ， 可 能 并 不 能 如 愿 。 不 过 ， 在 本 书 中 ， 你 将 知道 mnoDB 存 储 引 擎 是 
如 何 工作 的 ， 它 的 关键 特性 的 功能 和 作用 是 什么 ， 以 及 如 何 正确 配置 和 
使 用 这 些 特 性 。 


如 果 你 想 更 好 地 使 用 InnoDB 存 储 引 擎 ， 如 果 你 想 让 你 的 数据 库 应 
用 获得 更 好 的 性 能 ， 就 请 阅读 本 书 。 从 某 种 程度 上 讲 ， 技 术 经 理 或 总 监 
也 要 非常 了 解数 据 库 ， 要 知道 数据 库 对 于 企业 的 重要 性 。 如 果 技 术 经 理 
或 总 监 想 安排 员工 参加 MySQL 数 据 库 技术 方面 的 增 训 ， 完 全 可 以 利用 
本 书 来 “充电 ”， 相 信 你 一 定 不 会 失望 的 。 

要 想 更 好 地 学 习 本 书 的 内 容 ， 要 求 具备 以 下 条 件 : 

Q3ÉSÉSQL. 

口 掌握 基本 的 MySQL 操 作 。 

口 接触 过 一 些 高 级 语言 ， 如 C、C++、Python 或 Java。 


口 对 一 些 基 本 算法 有 所 了 解 ， 因 为 本 书 会 分 析 InnoDB 存 储 引擎 的 
部 分 源 代 码 ， 如 果 你 能 看 懂 这 些 算法 ， 这 会 对 你 的 理解 非常 有 帮助 。 




















如 何 阅读 本 书 


本 书 一 共有 10 章 ， 每 一 章 都 像 一 本 “迷你 书 ”， 可 以 单独 成 肌 ， 也 束 
说 你 完全 可 以 从 书 中 任何 一 章 开 始 阅读 。 例 如 ， 要 了 解 第 10 章 中 的 
InnoDB 源 代码 编译 和 调试 的 知识 ， 束 不 必 先 去 阅读 第 3 章 有 关 文 件 的 知 
识 。 当 然 ， 如 果 你 不 太 确 定 自 己 是 否 已 经 对 本 书 所 涉及 的 内 容 完 全 掌握 
了 ， 建 议 你 系统 性 地 阅读 本 书 。 


本 书 不 是 一 本 入 门 书籍 ， 不 会 一 步 步 引导 你 去 如 何 操作 。 倘 重 你 尚 
不 了 解 InnoDB 人 存储 引擎 ， 本 书 对 你 来 说 可 能 就 显得 沉重 一 些 ， 建 议 你 
先 查 阅 官方 的 API 文 档 ， 大 致 掌握 InnoDB 的 基础 知识 ， 然 后 再 来 学 习 本 
书 ， 相 信 你 会 领略 到 不 同 的 风景 。 


为 了 便于 大 家 阅读 ， 本 书 在 提供 源 代 码 下 载 〈( 下 载 地 址 : 
www.hzbook.com) 的 同时 也 将 源 代 码 附 在 了 书 中 ， 因 此 占 去 了 一 些 篇 
幅 ， 还 请 大 家 理解 。 
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由 于 作者 对 InnoDB 存 储 引 擎 的 认 知 水 平 有 限 ， 再 加 上 写作 时 可 能 
存在 疏漏 ， 书 中 还 存在 许多 需要 改进 的 地 方 。 在 此 ， 欢 迎 读者 朋友 们 指 
出 书 中 存在 的 问题 ， 并 提出 指导 性 意见 ， 不 其 感谢 。 如 果 大 家 有 任何 与 
本 书 相 关 的 内 容 需 要 与 我 探讨 ， 请 发 邮件 到 jiangchengyao@gmail.com， 
或 者 通过 新 浪 微 博 @insidemysgl 与 我 联系 ， 我 会 及 时 给 予 回 复 。 最 后 ， 
衷心 地 希望 本 书 能 给 大 家 市 来 帮助 ， 并 祝 大 家 阅读 愉快 ! 











致谢 


在 编写 本 书 的 过 程 中 ， 我 得 到 了 很 多 朋友 的 热心 帮助 。 首 先 要 感谢 
Pecona 公 司 的 CEO Peter Zaitsev 和 CTO Vadim Tkachenko， 通 过 和 他 们 的 
不 断交 流 ， 使 我 对 ImnoDB 存 储 引 擎 有 了 更 进一步 的 了 解 ， 同 时 知道 了 
怎样 才能 正确 地 将 ImnoDB 存 储 引 擎 的 补丁 应 用 到 生产 环境 。 


其 次 ， 要 感谢 网 易 公 司 的 各 位 同事 们 ， 能 在 才华 横 溢 、 充 满 创意 的 
团队 中 工作 我 感到 非常 荣誉 和 兴奋 。 也 因为 在 这 个 开放 的 工作 环境 中 ， 
我 可 以 不 断 进行 研究 和 创新 。 


此 外 ， 我 还 要 感谢 我 的 母亲 ， 写 本 书 不 是 一 件 容 易 的 事 ， 特 别 是 这 
本 书 还 想 传达 一 些 思想 ， 在 这 个 过 程 中 我 遇 到 了 很 多 的 困难 ， 感 谢 她 在 
这 个 过 程 中 给 予 我 的 支持 和 至 励 。 


最 后 ， 一 份 特别 的 感谢 要 送 给 本 书 的 策划 编辑 杨 福 川 和 委 影 ， 他 们 
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第 1 章 ，MySQL 体 系 结构 和 存储 引擎 


MySQL 被 设计 为 一 个 可 移植 的 数据 库 ， 几 乎 在 当前 所 有 系统 上 都 
能 运行 ， 如 Linux，Solaris、FreeBSD、Mac 和 Windows。 尽 管 各 平台 在 
底层 〈 如 线程 ) 实现 方面 都 各 有 不 同 ， 但 是 MySQL 基 本 上 能 保证 在 各 
平台 上 的 物理 体系 结构 的 一 致 性 。 因 此 ， 用 户 应 该 能 很 好 地 理解 
MySQL 数 据 库 在 所 有 这 些 平 台 上 是 如 何 运 作 的 。 


1.1 定义 数据 库 和 实例 


在 数据 库 领 域 中 有 两 个 词 很 容易 混 消 ， 这 束 是 “数据 
FE" (database) 和 “实例 ”(instance〉)。 作 为 常见 的 数据 库 术 语 ， 这 两 个 
词 的 定义 如 下 。 


Qum: 物理 操作 系统 文件 或 其 他 形式 文件 类 型 的 集合 。 在 
MySQL 数 据 库 中 ， 数 据 库 文 件 可 以 是 frm、MYD、MYI、ibd 结 尾 的 文 
件 。 当 使 用 NDB 引 擎 时 ， 数 据 库 的 文件 可 能 不 是 操作 系统 上 的 文件 ， 而 
是 存放 于 内 存 之 中 的 文件 ， 但 是 定义 仍然 不 变 。 


口 实例 : MySQL 数 据 库 由 后 人 台 线 程 以 及 一 个 共享 内 存 区 组 成 。 共 
译 内 存 可 以 被 运行 的 后 侣 线程 所 共享 。 需 要 牢记 的 是 ， 数 据 库 实例 才 是 
真正 用 于 操作 数据 库 文件 的 。 


这 两 个 词 有 时 可 以 互 换 使 用 ， 不 过 两 者 的 概念 完全 不 同 。 在 
MySQL 数 据 库 中 ， 实 例 与 数据 库 的 天 通 第 系 是 一 一 对 应 的 ， 即 一 个 实 
例 对 应 一 个 数据 库 ， 一 个 数据 库 对 应 一 个 实例 。 但 是 ， 在 集群 情况 下 可 
能 存在 一 个 数据 库 被 多 个 数据 实例 使 用 的 情况 。 


MySQL 被 设计 为 一 个 单 进程 多 线程 架构 的 数据 库 ， 这 点 与 SQL 
Server 比 较 类 似 ， 但 与 Oracle 多 进程 的 架构 有 所 不 同 (Oracle 的 Windows 
版 本 也 是 单 进程 多 线程 架构 的 ) 。 这 也 就 是 说 ，MySQL 数 据 库 实例 在 
系统 上 的 表现 就 是 一 个 进程 。 


在 Linux 操 作 系 统 中 通过 以 下 命令 局 动 MySQL 数 据 库 实例 ， 并 通过 
命令 ps 观察 MySQL 数 据 库 局 动 后 的 进程 情况 : 




















[rootQxen-server bin]#./mysqld_safe& 

oot@xen-server bil s-ef|grep mysqld 
ot 3441 3258 0 10:23 pts/3 00:00:00/bin/sh./mysqld_safe 
00:00 


/usr/local/mysql/libexec/mysqld- -basedir=/usr/local/mysql 

datadir s l/m var --user=mysql 

.err 
rver 

--socket-/tmp/mysql.sock--port-3306 
root 3616 3258 0 10:27 pts/3 00:00:00 grep mysqld 
注意 进程 号 为 3578 的 进程 ， 该 进程 就 是 实例 。 在 上 述 例子 
注意 进程 号 为 3578 的 进程 ， 该 进程 融 是 MYSQL 实例 。 在 上 述 侦 


中 使 用 了 mysqld_safe 命 令 来 局 动 数据 库 ， 当 然 司 动 MYSQL 实例 的 方法 
还 有 很 多 ， 在 各 种 平台 下 的 方式 可 能 又 会 有 所 不 同 。 在 这 里 不 一 一 更 


当局 动 实例 时 ，MySQL 数 据 库 会 去 读 取 配置 文件 ， 根 据 配 置 文件 
的 参数 来 启动 数据 库 实 例 。 这 与 Oracle 的 参数 文件 〈spfile) 相似 ， 不 同 
的 是 ，Oracle 中 如 果 没 有 参数 文件 ， 在 启动 实例 时 会 提示 找 不 到 该 参数 
文件 ， 数 据 库 启动 失败 。 而 在 MySQL 数 据 库 中 ， 可 以 没有 配置 文件 ， 
MySQL 会 按照 编译 时 的 默认 参数 设置 启动 实例 。 用 以 
i 令 可 以 查看 当 MySQL 数 据 库 实例 启动 时 ， 会 在 哪些 位 置 查 找 配 置 
。 o 











[root@xen-server bin]#mysql--help|grep my.cnf 
order of preference,my.cnf,$MYSQL TCP PORT, 
/etc/my.cnf/etc/mysql/my.cnf/usr/local/mysql/etc/my.cnf-—/.my.cnf 





可 以 看 到 ，MySQL 数 据 库 是 
按 /etc/my.cnf 5 /etc/mysql/my.cnf > /usr/local/mysql/etc/my.cnf ^ ~/.my.cnf 
的 顺序 读 取 配置 文件 的 。 可 能 有 读者 会 问 :“ 如 果 几 个 配置 文件 中 都 有 
同一 个 参数 ，MySQL 数 据 库 以 哪个 配置 文件 为 准 ? ”答案 很 简单 ， 
MySQL 数 据 库 会 以 读 取 到 的 最 后 一 个 配置 文件 中 的 参数 为 准 。 在 Linux 
环境 下 ， 配 置 文件 一 般 放 在 /etc/my.cnf 下 。 在 Windows 平 台 下 ， 配 置 文 
件 的 后 级 名 可 能 是 .cnf， 也 可 能 是 .ini。 例 如 在 Windows 操 作 系 统 下 运行 
mysql--help， 可 以 找到 如 下 类 似 内 容 : 








Default options are read from the following files in the given order: 
C:\Windows\my.ini C:\Windows\my.cnf C:\my.ini C:\my.cnf C:\Program Files\MySQL\M 
\MySQL Server 5.1\my.cnf 





配置 文件 中 有 一 个 参数 datadir， 访 参数 指定 了 数据 库 所 在 的 路 径 。 
在 Linux 操 作 系 0 o d A ep) HA 用 户 可 以 修改 该 
参数 ， 当 然 也 可 以 使 用 该 路 径 ， 不 过 该 路 径 只 是 一 个 链接 ， 有 具体 如 下 : 





mysql>SHOW VARIABLES LIKE'datadir'\G; 
KKEKEKEKEKEKEKEKEKEKEKEKEKKJ POEK IOI III III III IOI II Gk 
Variable_name:datadir 

Value: /usr/local/mysql/data/ 

1 row in set(0.00 sec)1 row in set(0.00 sec) 

mysql>system ls-lh/usr/local/mysql/data 

total 32K 

drwxr-xr-x 2 root mysql 4.0K Aug 6 16:23 bin 

drwxr-xr-x 2 root mysql 4.0K Aug 6 16:23 docs 

drwxr-xr-x 3 root mysql 4.0K Aug 6 16:04 include 

drwxr-xr-x 3 root mysql 4.0K Aug 6 16:04 lib 

drwxr-xr-x 2 root mysql 4.0K Aug 6 16:23 libexec 

drwxr-xr-x 10 root mysql 4.0K Aug 6 16:23 mysql-test 
drwxr-xr-x 5 root mysql 4.0K Aug 6 16:04 share 

drwxr-xr-x 5 root mysql 4.0K Aug 6 16:23 sql-bench 
lrwxrwxrwx 1 root mysql 16 Aug 6 16:05 data->/opt/mysql_data/ 


p—M—————————————————————————————————à 





从 上 面 可 以 看 到 ， 其 实 data 目 录 是 一 个 链接 ， 该 链接 指 辐 
了 /optmysql_data 目 录 。 当 然 ， 用 户 必 须 保 证 /optmysql_data 的 用 户 和 权 
限 ， 使 得 只 有 mysql 用 户 和 组 可 以 访问 《通常 MySQL 数 据 库 的 权限 为 
mysql : mysql) 。 


1.2 ”MySQL 体系 结构 

由 于 工作 的 缘故 ， 笔 者 的 大 部 分 时 间 需 要 与 开发 人 员 进行 数据 库 方 
面 的 沟通 ， 并 对 他 们 进行 培训 。 不 论 他 们 是 DBA， 还 是 开发 人 员 ， 似 乎 
都 对 MySQL 的 体系 结构 了 解 得 不 够 透彻 。 很 多 人 喜欢 把 MySQL 与 他 们 
以 前 使 用 的 SQL Server、Oracle、DB2 作 比较 。 因 此 笔者 常常 会 听 到 这 
样 的 疑问 : 

口 为 什么 MySQL 不 文 持 全 文 索引 ? 

口 MySQL 速 度 快 是 因为 它 不 文 持 事务 吗 ? 


口 数据 量 大 于 1000 万 时 MySQL 的 性 能 会 急剧 下 降 吗 ? 











对 于 MySQL 数 据 库 的 疑问 有 很 多 很 多 ， 在 解释 这 些 问题 之 前 ， 笔 
者 认为 不 管 对 于 使 用 哪 种 数据 库 的 开发 人 员 ， 了 解数 据 库 的 体系 结构 都 
古 最 为 重要 的 内 容 。 


在 给 出 体系 结构 图 之 前 ， 用 户 应 该 理解 了 前 一 节 提 出 的 两 个 概念 : 
数据 库 和 数据 库 实 例 。 很 多 人 会 把 这 两 个 概念 混 请 ， 即 MySQL 是 数据 
库 ，MySQL 也 是 数据 库 实 例 。 这 样 来 理解 Oracle 和 Microsoft SQL Server 
数据 库 可 能 是 正确 的 ， 但 是 这 会 给 以 后 理解 MySQL 体 系 结构 中 的 存储 
引擎 带 来 问题 。 从 概念 上 来 说 ， 数 据 库 是 文件 的 集合 ， 是 依照 某 种 数据 
模型 组 织 起 来 并 存放 于 二 级 存储 器 中 的 数据 集合 数据 库 实 例 是 程序 ， 
是 位 于 用 户 与 操作 系统 之 间 的 一 层 数 据 管 理 软件 ， 用 户 对 数据 库 数 据 的 
任何 操作 ， 包 括 数据 库 定 义 、 数 据 查 询 、 数 据 维 护 、 数 据 库 运 行 控 制 等 
a a 
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如 果 这 样 讲解 后 读者 还 是 不 明白 ， 那 这 里 再 换 一 种 更 为 直 白 的 方式 
来 解释 : 数据 库 是 由 一 个 个 文件 组 成 〈 一 般 来 说 都 是 二 进 制 的 文件 ) 
的 ， 要 对 这 些 文件 执行 诸如 SELECT、INSERT、UPDATE 和 DELETE 之 
类 的 数据 库 操 作 是 不 能 通过 简单 的 操作 文件 来 更 改 数据 库 的 内 容 ， 需 要 
通过 数据 库 实例 来 完成 对 数据 库 的 操作 。 所 以 ， 用 户 把 Oracle、SQL 
Server、MySQL 简 单 地 理解 成 数据 库 可 能 是 有 失 偏 颇 的 ， 虽 然 在 实际 使 



































用 中 并 不 会 这 么 强调 两 者 之 间 的 区 别 。 


好 了 ， 在 给 出 上 述 这 些 复杂 枯燥 的 定义 后 ， 现 在 可 以 来 看 看 
ae ce pena tons 其 结构 如 图 1-1 所 示 〈 摘 自 MySQL 官 方 手 
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图 1-31 MySQL 体系 结构 

从 图 1-1 可 以 发 现 ，MySQL 由 以 下 几 部 分 组 成 : 

口 连 接 池 组 件 

口 管理 服务 和 工具 组 件 

口 SQL 接口 组 件 

口 查询 分 析 器 组 件 

口 优化 器 组 件 

口 缓冲 (Cache) 组 件 

口 插件 式 存储 引擎 

口 物理 文件 

从 图 1-1 还 可 以 发 现 ，MySQL 数 据 库 区 别 于 其 他 数据 库 的 最 重要 的 
一 个 特点 就 是 其 插件 式 的 表 存 储 引 擎 。MySQL 插 件 式 的 存储 引擎 架构 
提供 了 一 系列 标准 的 管理 和 服务 文 持 ， 这 些 标准 与 存储 引擎 本 身 无 关 ， 
可 能 是 每 个 数据 库 系 统 本 身 都 必需 的 ， 如 SQL 分 析 器 和 优化 器 等 ， 而 存 
储 引 擎 是 底层 物理 结构 的 实现 ， 每 个 存储 引擎 开发 者 可 以 按照 自己 的 意 
愿 来 进行 开发 。 

需要 特别 注意 的 是 ， 存 储 引 擎 是 基于 表 的 ， 而 不 是 数据 库 。 此 外 ， 


要 牢记 图 1-1 的 MySQL 体 系 结构 ， 它 对 于 以 后 深入 理解 MySQL 数 据 库 会 
有 极 大 的 帮助 。 








1.5 ”MySQL 存储 引擎 


通过 1.2 节 大 致 了 解 J 了 MySQL 数据 库 独 有 的 插件 式 体系 结构 ， 并 了 
解 到 存储 引擎 是 MySQL 区 别 于 其 他 数据 库 的 一 个 最 重要 特性 。 存 储 引 
擎 的 好 处 是 ， 每 个 存储 引擎 都 有 各 目的 特点 ， 能 够 根据 具体 的 应 用 建立 
不 同 存储 引擎 表 。 对 于 开发 人 员 来 说 ， 存 储 引 擎 对 其 是 透明 的 ， 但 了 解 
各 种 存储 引擎 的 区 别 对 于 开发 人 员 来 说 也 是 有 好 处 的 。 对 于 DBA 来 说 ， 
他 们 应 该 深刻 地 认识 到 MySQL 数 据 库 的 核心 在 于 存储 引擎 。 


由 于 MySQL 数 据 库 的 开源 特性 ， 用 户 可 以 根据 MySQL 预 定义 的 存 
储 引 擎 接口 编写 自己 的 存储 引擎 。 知 用 户 对 某 一 种 存储 引擎 的 性 能 或 功 
能 不 满意 ， 可 以 通过 修改 源码 来 得 到 想 要 的 特性 ， 这 就 是 开源 带 给 我 们 
的 方便 与 力量 。 比 如 ，eBay 的 工程 师 Igor Chernyshev*j MySQL Memory 
存储 引擎 的 改进 Chttp://code.google.com/p/mysql-heap-dynamic-rows/ ) 
并 应 用 于 eBay 的 Personalization Platform， 类 似 的 修改 还 有 Google 和 
Facebook 等 公司 。 笔 者 曾 尝 试 过 对 InnoDB 存 储 引 擎 的 缓冲 池 进 行 扩展 ， 
为 其 添加 了 基于 SSD 的 辅助 缓冲 池上 J， 通 过 利用 SSD 的 高 随机 读 取 性 能 3 
进一步 提高 数据 库 本 身 的 性 能 。 当 然 ，MySQL 数 据 库 自身 提供 的 存储 
引擎 已 经 足够 满足 绝 大 多 数 应 用 的 需求 。 如 采用 户 有 兴趣 ， 完 全 可 以 开 
发 自己 的 存储 引擎 ， 满 足 自 己 特定 的 需求 。MySQL 官 方 手册 的 第 16 章 
2d 了 编写 目 定 义 存 储 引 擎 的 过 程 ， 不 过 这 已 超出 了 本 书 所 涵盖 的 范 
è 























由 于 MySQL 数 据 库 开源 特性 ， 存 储 引 擎 可 以 分 为 MySQL 官 方 存储 
引擎 和 第 三 方 存储 引擎 。 有 些 第 三 方 存储 引擎 很 强大 ， 如 大 名 易 易 的 
InnoDB 存 储 引 擎 《最 早 是 第 三 方 存储 引擎 ， 后 被 Oracle 收 购 ) ， 其 应 用 
就 极其 广泛 ， 甚 至 是 MySQL 数 据 库 OLTP COnline Transaction Processing 
在 线 事务 处 理 ) 应 用 中 使 用 最 广泛 的 存储 引擎。 还 是 那 句 话 ， 用 户 应 该 
根据 具体 的 应 用 选择 适合 的 存储 引擎 ， 以 下 是 对 一 些 存储 引擎 的 简单 介 
绍 ， 以 便于 读者 选择 存储 引擎 时 参考 。 


1.3.1 _ InnoDB 存 储 引擎 
InnoDB 存 储 引擎 支持 事务 ， 其 设计 目标 主要 而 向 在 线 事务 处 理 


COLTP) 的 应 用 。 其 特点 是 行 锁 设计 、 文 持 外 键 ， 并 文 持 类 似 于 Oracle 
的 非 锁定 读 ， 即 默认 读 取 操 作 不 会 产生 锁 。 从 MySQL 数 据 库 5.5.8 版 本 














开始 ，InnoDB 存 储 引 擎 是 默认 的 存储 引擎 。 


InnoDB 存 储 引擎 将 数据 放 在 一 个 逻辑 的 表 空 间 中 ， 这 个 表 空 间 职 
像 黑 盒 一 样 由 InnoDB 存 储 引 擎 自身 进行 管理 。 从 MySQL 431 (包括 
4.1) 版 本 开始 ， 它 可 以 将 每 个 mnoDB 存 储 引擎 的 表单 独 存 放 到 一 个 独 
芯 的 和 bd 文件 中 。 此 外 ，InnoDB 存 储 引 擎 文 持 用 裸 设 备 (Crow disk) 用 来 
建立 其 表 空 间 。 


InnoDB 通 过 使 用 多 版 本 并 发 控制 (MVCC) 来 获得 高 并 发 性 ， 并 且 
实现 了 SQL 标准 的 4 种 隔离 级 别 ， 默 认为 REPEATABLE 级 别 。 同 时 ， 使 
用 一 种 被 称 为 next-key — locking HJR MARI HATE (phantom) 现象 的 产 
生 。 除 此 之 外 ，InnoDB 储 存 引 擎 还 提供 了 插入 绥 冲 Cinsert buffer) ~ = 
YRS (double write) 、 目 适应 哈 希 索引 (adaptive hash index) 、 预 读 
(read ahead) 等 高 性 能 和 高 可 用 的 功能 。 


对 于 表 中 数据 的 存储 ，InnoDB 存 储 引 苟 采用 了 聚集 (clustered) 的 
方式 ， 因 此 每 张 表 的 存储 都 是 按 主键 的 顺序 进行 存放 。 如 果 没 有 显 式 地 
在 表 定 义 时 指定 主键 ，InnoDB 存 储 引擎 会 为 每 一 行 生 成 一 个 6 字 节 的 
ROWID， 并 以 此 作为 主键 。 


InnoDB 存 储 引 擎 是 MySQL 数 据 库 最 为 常用 的 一 种 引擎 ， 而 
Facebook, Google. Yahoo! 等 公司 的 成 功 应 用 已 经 证 明了 InnoDB 存 储 
引擎 具备 的 高 可 用 性 、 高 性 能 以 及 高 可 扩展 性 。 














UNJ: http://code.google.com/p/david-mysql- 
tools/wiki/innodb_secondary_buffer_pool 


1.3.2 MyISAM E f 5| SE 


MyISAM 存 储 引 擎 不 文 持 事 务 、 表 锁 设 计 ， 文 持 全 文 索引 ， 主 要 面 
向 一 些 OLAP 数 据 库 应 用 。 在 MySQL 5.5.8 版 本 之 前 MyISAM 存 储 引 擎 是 
默认 的 存储 引擎 〈 除 Windows 版 本 外 ) 。 数 据 库 系 统 与 文件 系统 很 大 的 
一 个 不 同 之 处 在 于 对 事务 的 支持 ， 然 而 MyISAM 存 储 引 擎 是 不 支持 事务 
的 。 究 其 根本 ， 这 也 不 是 很 难 理解 。 试 想 用 户 是 否 在 所 有 的 应 用 中 都 需 
要 事务 呢 ? 在 数据 仓库 中 ， 如 果 没 有 ETL 这 些 操作 ， 只 是 简单 的 报表 查 
询 是 否 还 需要 事务 的 支持 呢 ?” 此 外 ，MyISAM 存 储 引 擎 的 男 一 个 与 众 不 
同 的 地 方 是 它 的 缓冲 池 只 缓存 (cache)〉 索引 文件 ， 而 不 缓冲 数据 文 
件 ， 这 点 和 大 多 数 的 数据 库 都 非常 不 同 。 


MVyISAM 存 储 引 擎 表 由 MYD 和 MYI 组 成 ，MYD 用 来 存放 数据 文 
件 ，MYI 用 来 存放 索引 文件 。 可 以 通过 使 用 myisampack 工 具 来 进一步 压 
"ud dst. Al Amyisampack L H.fit pA (Huffman) 编码 静态 算 
法 来 压缩 数据 ， 因 此 使 用 myisampack 工 具 压 缩 后 的 表 是 只 读 的 ， 当 然 用 
户 也 可 以 通过 myisampack 来 解压 数据 文件 。 


在 MySQL 5.0 版 本 之 前 ，MyISAM 默 认 支 持 的 表 大 小 为 4GB， 如 果 
需要 支持 大 于 4GB 的 MyISAM 表 时 ， 则 需要 制定 MAX_ROWS 和 
AVG_ROW_LENGTH 属 性 。 从 MySQL 5.0 版 本 开始 ，MyISAM 默 认 支 持 
256TB 的 单 表 数据 ， 这 足够 满足 一 般 应 用 需求 。 


注意 ”对 于 MyISAM 存 储 引 擎 表 ，MySQL 数 据 库 只 缓存 其 索引 文 
件 ， 数 据 文件 的 缓存 交 由 操作 系统 本 身 来 完成 ， 这 与 其 他 使 用 LRU 算 法 
缓存 数据 的 大 部 分 数据 库 大 不 相同 。 此 外 ， 在 MySQL 5.1.23 版 本 之 前 ， 
无 论 是 在 32 位 还 是 64 位 操作 系统 环境 下 ， 组 存 索 引 的 缓冲 区 最 大 只 能 设 
人 在 之 后 的 版 本 中 ，64 位 系统 可 以 文 持 大 于 4GB 的 索引 缓冲 
Xo 

















1.83 NDB 存 储 引擎 


20034E, MySQL AB 公 司 从 Sony Ericsson 公 司 收 购 了 NDB 集 群 引擎 
〈 见 图 1-1) 。NDB 存 储 引擎 是 一 个 集群 存储 引擎 ， 类 似 于 Oracle 的 RAC 
集群 ， 不 过 与 Oracle RAC share everything 架 构 不 同 的 是 ， 其 结构 是 share 
nothing 的 集群 架构 ， 因 此 能 提供 更 高 的 可 用 性 。NDB 的 特点 是 数据 全 部 
放 在 内 存 中 (从 MySQL 5.1 版 本 开始 ， 可 以 将 非 索引 数据 放 在 磁盘 
E) ， 因 此 主键 查找 (primary key lookups) 的 速度 极 快 ， 并 且 通 过 添 
加 NDB 数 据 存 储 节 点 (Data Node) 可 以 线性 地 提高 数据 库 性 能 ， 是 高 
可 用 、 高 性 能 的 集群 系统 。 


关于 NDB 存 储 引 擎 ， 有 一 个 问题 值得 注意 ， 那 就 是 NDB 人 存储 引擎 
的 连接 操作 〈JOIN) 是 在 MySQL 数 据 库 层 完成 的 ， 而 不 是 在 存储 引擎 
层 完成 的 。 这 意味 看 ， 复 杂 的 连接 操作 需要 巨大 的 网 络 开 销 ， 因 此 查询 
~ 如 果 解 决 了 这 个 问题 ，NDB 存 储 引擎 的 市 场 应 该 是 非常 巨大 


注意 MySQL NDB Cluster 存 储 引擎 有 社区 版 本 和 企业 版 本 两 种 ， 
并 且 NDB Cluster 已 作为 Carrier Grade Edition 单 独 下 载 版 本 而 存在 ， 可 以 


通过 http://dev.mysql.com/downloads/cluster/index.html 获 得 最 新 版 本 的 
NDB Cluster 存 储 引擎 。 














1.3.4 Memory 存储 引擎 


Memory 存 储 引 擎 〈 之 前 称 HEAP 存 储 引 擎 ) 将 表 中 的 数据 存放 在 内 
存 中 ， 如 果 数 据 库 重 启 或 发 生 朋 演 ， 表 中 的 数据 都 将 消失 。 它 非常 适合 
用 于 存储 临时 数据 的 临时 表 ， 以 及 数据 仓库 中 的 纬度 表 。Memory 存 储 
引擎 默认 使 用 哈 希 索引 ， 而 不 是 我 们 熟悉 的 B+ 树 索引 。 


虽然 Memory 存 储 引 擎 速度 非常 快 ， 但 在 使 用 上 还 是 有 一 定 的 限 
制 。 比 如 ， 只 文 持 表 锁 ， 并 发 性 能 较 差 ， 并 且 不 文 持 TEXT 和 BLOB 列 
类 型 。 最 重要 的 是 ， 存 储 变 长 字段 (varcha 时 是 按照 定常 字段 
(char) 的 方式 进行 的 ， 因 此 会 浪费 内 存 〈( 这 个 问题 之 前 已 经 提 到 ， 
eBay 的 工程 师 Igor Chernyshev 已 经 给 出 了 patch 解 决 方案 ) 。 


此 外 有 一 点 容易 被 忽视 ，MySQL 数 据 库 使 用 Memory 存 储 引 擎 作为 
临时 表 来 存放 查询 的 中 间 结 果 集 (intermediate result) 。 如 果 中 间 结 果 
集 大 于 Memory 存 储 引 擎 表 的 容量 设置 ， 又 或 者 中 间 结 果 含 有 TEXT 或 
BLOB 列 类 型 字段 ， 则 MySQL 数 据 库 会 把 其 转换 到 MyISAM 存 储 引 擎 表 
而 存放 到 磁盘 中 。 之 前 提 到 MyISAM 不 缓存 数据 文件 ， 因 此 这 时 产生 的 
临时 表 的 性 能 对 于 查询 会 有 损失 。 
































1.3.5 Archive fht 5| 2 


Archive 存 储 引 擎 只 支持 INSERT 和 SELECT 操作 ， 从 MySQL 5.1 开 始 
支持 索引 。Archive 存 储 引擎 使 用 zlib 算 法 将 数据 行 Cow) 进行 压缩 后 
存储 ， 压 缩 比 一 般 可 达 1 : 10。 正 如 其 名 字 所 示 ，Archive 存 储 引 擎 非常 
适合 存储 归档 数据 ， 如 日 志 信 息 。Archive 存 储 引擎 使 用 行 锁 来 实现 高 
并 发 的 插入 操作 ， 但 是 其 本 寻 并 不 是 事务 安全 的 存储 引擎 ， 其 设计 目标 
主要 是 提供 高 速 的 插入 和 压缩 功能 。 











1.3.6 Federated F fi 5| 2% 


Federated 存 储 引 擎 表 并 不 存放 数据 ， 它 只 是 指 网 一 台 远 程 MySQL 
数据 库 服 务 器 上 的 表 。 这 非常 类 似 于 SQL ”Server 的 链接 服务 器 和 Oracle 
的 透明 网 关 ， 不 同 的 是 ， 当 前 Federated 存 储 引擎 只 支持 MySQL 数 据 库 
表 ， 不 文 持 异 构 数据 库 表 。 











1.8.7 ”Maria 存储 引擎 


Maria 存 储 引擎 是 新 开发 的 引擎 ， 设 计 目 标 主要 是 用 来 取代 原 有 的 
MyYISAM 存 储 引 擎 ， 从 而 成 为 MySQL 的 默认 存储 引擎 。Maria 存 储 引 擎 
的 开发 者 是 MySQL 的 创始 人 之 一 的 Michael Widenius。 因 此 ， 它 可 以 看 
做 是 MyISAM 的 后 续 版 本 。Maria 存 储 引 警 的 特点 是 : 支持 缓存 数据 和 
索引 文件 ， 应 用 了 行 锁 设计 ， 提 供 了 MVCC 功 能 ， 支 持 事务 和 非 事务 安 
全 的 选项 ， 以 及 更 好 的 BLOB 字 符 类 型 的 处 理性 能 。 





1.3.8 其 他 存储 引擎 


除了 上 面 提 到 的 7 种 存储 引擎 外 ，MySQL 数 据 库 还 有 很 多 其 他 的 存 
储 引 擎 ， 包 括 Merge、CSV、Sphinx 和 Infobright， 它 们 都 有 各 自 使 用 的 
场合 ， 这 里 不 再 一 一 介绍 。 在 了 解 MySQL 数 据 库 拥 有 这 么 多 存储 引擎 
后 ， 现 在 我 可 以 回答 1.2 节 中 提 到 的 问题 了 。 


口 为 什么 MySQL 数 据 库 不 支持 全 文 索引 ? 不 ! MySQL 文 持 ， 
MyISAM, InnoDB (1.2 版 本 ) 和 Sphinx 存 储 引 擎 都 支持 全 文 索引 。 


DMySQL 数 据 库 速度 快 是 因为 不 支持 事务 ? 错 ! 虽然 MySQL 的 
MyISAM 存 储 引 警 不 支持 事务 ， 但 是 InnoDB 文 持 。“ 快 ”是 相对 于 不 同 应 
用 来 说 的 ， 对 于 ETL 这 种 操作 ，MyISAM 会 有 其 优势 ， 但 在 OLTP 环 境 
中 ，InnoDB 存 储 引擎 的 效率 更 好 。 


口 当 表 的 数据 量 大 于 1000 万 时 MySQL 的 性 能 会 急剧 下 降 吗 ? 不 ! 
MySQL 是 数据 库 ， 不 是 文件 ， 随 着 数据 行 数 的 增加 ， 人 性 能 当然 会 有 所 
下 降 ， 但 是 这 些 下 降 不 是 线性 的 ， 如 果 用 户 选 择 了 正确 的 存储 引擎 ， 以 
及 正确 的 配置 ， 再 多 的 数据 量 MySQL 也 能 承受 。 如 官方 手册 上 提 及 
的 ，Mytrix 和 Inc. 在 InnoDB 上 存储 超过 1 TB 的 数据 ， 还 有 一 些 其 他 网 站 
使 用 ImnoDB 存 储 引 擎 ， 处 理 插 入 /更 新 的 操作 平均 800 次 / 秒 。 








1.4 各 存储 引擎 之 间 的 比较 


通过 1.3 市 的 介绍 ， 我 们 了 解 了 存储 引擎 是 MySQL 体 系 结构 的 核 
心 。 本 节 我 们 将 通过 简单 比较 几 个 存储 引擎 来 让 读者 更 直观 地 理解 存储 
引擎 的 概念 。 图 1-2 取 自 于 MySQL 的 官方 手册 ， 展 现 了 一 些 常用 MySQL 
存储 引擎 之 间 的 不 同 之 处 ， 包 括 存 储 容量 的 限制 、 事 务 支 持 、 锁 的 粒 
度 、MVCC 文 持 、 文 持 的 索引 、 备 份 和 复制 等 。 
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图 12 不 同 MySQL 存 储 引擎 相关 特性 比较 


可 以 看 到 ， 每 种 存储 引擎 的 实现 都 不 相同 。 有 些 竟然 不 文 持 事务 ， 
相信 在 任何 一 本 关于 数据 库 原 理 的 书 中 ， 可 能 都 会 提 到 数据 库 与 传统 文 
件 系 统 的 最 大 区 别 在 于 数据 库 是 支持 事务 的 。 而 MySQL 数 据 库 的 设计 
者 在 开发 时 却 认为 可 能 不 是 所 有 的 应 用 都 需要 事务 ， 所 以 存在 不 支持 事 
务 的 存储 引擎 。 更 有 不 明 其 理 的 人 把 MySQL 称 做 文件 系统 数据 库 ， 其 
实 不 然 ， 只 是 MySQL 数 据 库 的 设计 思想 和 存储 引擎 的 关系 可 能 让 人 产 
生 了 理解 上 的 偏差 。 


可 以 通过 SHOW ENGINES 语 句 查 看 当前 使 用 的 MySQL 数 据 库 所 文 
持 的 存储 引擎 ， 也 可 以 通过 查找 information_schema 架 构 下 的 ENGINES 
表 ， 如 下 所 示 : 








mysql>SHOW ENGINES\G; 
JOOOOOOOOOOOROOOOOOOOOROIOOOOR] I pj FIG ICICI III III III Ie 
Engine: InnoDB 

Support: YES 

Comment :Supports transactions, row-level locking, and foreign keys 
Transactions: YES 

XA: YES 

Savepoints: YES 
JOOOOOOOOOOOOOOOCIOOOOOOOERK OK p yy FECT ICICI III III III Ie 
Engine:MRG_MYISAM 

Support: YES 

Comment:Collection of identical MyISAM tables 
Transactions :NO 

XA:NO 

Savepoints:NO 
JOOOOOOOOOOOROOOOOOOOOOOOOERE PQ) FICCI II ICICI III III III Ie 
Engine: BLACKHOLE 

Support: YES 

Comment:/dev/null storage engine(anything you write to it disappears) 
Transactions :NO 

XA:NO 

Savepoints:NO 
JOOOOOOOOOOOOOOOOOOOOOOOOOEOR AK pj FICCI III ICICI III III III Ie 
Engine:CSV 

Support: YES 

Comment :CSV storage engine 

Transactions :NO 

XA:NO 

Savepoints:NO 
JOOOOOOOOOCOOOOOOOOOOOOOERK B | pj FIGS ICICI III I III II I Ie 
Engine: MEMORY 

Support: YES 

Comment:Hash based,stored in memory,useful for temporary tables 
Transactions :NO 

XA:NO 

Savepoints:NO 
JOOOOOOOOOOOOOOOOOOOOOOOERRG | pj FI ICICI III ICICI III ICI III I ie 
Engine: FEDERATED 

Support :NO 

Comment : Federated MySQL storage engine 

Transactions: NULL 

XA: NULL 

Savepoints:NULL 
JOOOOOOOOOOOOOOOOOOOOOOOOOOR T pj FICCI II ICICI III III II I Ie 
Engine: ARCHIVE 

Support: YES 

Comment :Archive storage engine 

Transactions :NO 

XA:NO 

Savepoints:NO 
JOOOOOOOOOOOOOOOOOOOOOOOERR | pj CRCOOOOCOOOOOOOOOOOOOOOOROROK 
Engine:MyISAM 

Support:DEFAULT 

Comment:Default engine as of MySQL 3.23 with great performance 
Transactions:NO 

XA:NO 

Savepoints:NO 

8 rows in set(0.00 sec) 


| 








下 面 将 通过 MySQL 提 供 的 示例 数据 库 来 简单 显示 各 存储 引擎 之 间 
oe 这 里 将 分 别 运行 以 下 语句 ， 然 后 统计 每 次 使 用 各 存储 引擎 后 表 








mysql>CREATE TABLE m ENT in EN ngine=MyISAM 
d 

Query OK,2844047 r jos cte elt n sec) 

:0 


Wa ings 
mysql>ALTER TABLE mytest Engine Hah oDB; 
Query OK,2844047 rows atte Ds deiude 86 sec) 

Records:2844047 Duplicat ings:0 
mysql>ALTER TABLE myte et "En nói ie = ARCHIVE; 
Query OK, 2844047 rows e cte poen 03 se c) 

Records 12844047 Duplicates:0 Warnings:0 





通过 每 次 的 统计 ， 可 以 发 现 当 最 初 表 使 用 MyISAM 存 储 引 擎 时 ， 表 
的 大 小 为 40.7MB， 使 用 InnoDB 存 储 引 擎 时 表 增 大 到 了 113.6MB， 而 使 
用 Archive 存 储 引擎 时 表 的 大 小 却 上 只 有 20.2MB 。 该 例子 只 从 表 的 大 小 方 
面 简单 地 揭示 了 各 存储 引擎 的 不 同 。 


注意 ， MySQL 提供 了 一 个 非常 好 的 用 来 演示 MySQL 各 项 功能 的 示 
例 数 据 库 ， 如 SQL ”Server 提 供 的 AdventureWorks 示 例 数 据 库 和 Oracle 提 
供 的 示例 数据 库 。 据 我 所 知 ， 知 道 MySQL 示 例 数据 库 的 人 很 少 ， 可 能 
是 因为 这 个 示例 数据 库 没 有 在 安装 的 时 候 提 示 用 户 是 否 安装 〈 如 Oracle 
和 SQL Server) 以 及 这 个 示例 数据 库 的 下 载 竟然 和 文档 放 在 一 起 。 用 户 
可 以 通过 以 下 地 址 找到 并 下 载 示 例 数 据 库 : http://dev.mysql.com/doc/。 





1.5 连接 MySQL 


本 节 将 介绍 连接 MySQL 数 据 库 的 常用 方式 。 需 要 理解 的 是 ， 连 接 
MySQL 操 作 是 一 个 连接 进程 和 MySQL 数 据 库 实 例 进 行 通 信 。 从 程序 设 
计 的 角度 来 说 ， 本 质 上 是 进程 通信 。 如 果 对 进程 通信 比较 了 解 ， 可 以 知 
道 党 用 的 进程 通信 方式 有 管道 、 命 名 管道 、 命 名 字 、TCP/IP 套 接 字 、 
UNIX 域 套 接 字 。MySQL 数 据 库 提 供 的 连接 方式 从 本 质 上 看 都 是 上 述 提 
及 的 进程 通信 方式 。 


L5. TCP/IP 


TCP/IP 套 接 字 方 式 是 MySQL 数 据 库 在 任何 平台 下 都 提供 的 连接 方 
式 ， 也 是 网 络 中 使 用 得 最 多 的 一 种 方式 。 这 种 方式 在 TCP/IP 连 接 上 建立 
一 个 基于 网 络 的 连接 请 求 ， 一 般 情况 下 客户 端 (client) 在 一 台 服务 器 
上 ， 而 MySQL 实 例 (server) 在 另 一 台 服务 器 上 ， 这 两 台 机 器 通过 一 个 
TCP/IP 网 络 连 接 。 例 如 用 户 可 以 在 Windows 服 务 器 下 请 求 一 台 远 程 
Linux 服 务 器 下 的 MySQL 实 例 ， 如 下 所 示 : 




















C:\>mysql-h192.168.0.101-u david-p 

Enter password: 

Welcome to the MySQL monitor.Commands end with;or\g. 

Your MySQL connection id is 18358 

Server version:5.0.77-log MySQL Community Server(GPL) 
Type'help;'or'Mh'for help.Type'\c'to clear the current input statement. 
mysql> 





这 里 的 客户 端 是 windows， 它 向 一 台 Host IP 为 192.168.0.101 的 
MySQL 实 例 发 起 了 TCP/PP 连 接 请 求 ， 并 且 连 接 成 功 。 之 后 就 可 以 对 
MySQL 数 据 库 进 行 一 些 数据 库 操作 ， 如 DDL 和 DML 等 。 


这 里 需要 注意 的 是 ， 在 通过 TCP/IP 连 接 到 MySQL 实 例 时 ，MySQL 
数据 库 会 先 检查 一 张 权 限 视图 ， 用 来 判断 发 起 请 求 的 客户 端 IP 是 否 允 许 
连接 到 MySQL 实 例 。 该 视图 在 mysql 架 构 下 ， 表 名 为 user， 如 下 所 示 : 





mysql>USE mysql; 
Database changed 


host:192.168.24.% 

user:root 

password:*75DBD4FA548120B54FE693006C41AA9A16DE8FBE 
OROOOEOOROIOOIOOIOROIOOIOOIOOROOIOEOEX | p pE K K K KE A A K K K CCCI III ICICI I I I K a 
host:nineyou0-43 

user:root 

password: *75DBD4FA548120B54FE693006C41AA9A16DE8FBE 

FO III III II III IIGIGIE proe ekle elec eoe 


host:127.0.0.1 


user:root 
password: EEEE AEE E T AEE 
KKKERRRKKKKRRKKKKKR RAKKE R RKA | pE F K K K K A K KKE R K K K K KKK K K 
host:192.168.0.100 

user:zlm 

password: *DAE0939275CC7CD8bE0293812A31735DA9CF0953C 

FOI IGG ROROIOOOIOOOROOOEORK S | RO f K K K A K K K KK K K K KKK K K K KKK K K 
host :% 

user: david 

password: 

5 rows in set(0.00 sec) 





从 这 张 权限 表 中 可 以 看 到 ，MySQL 人 允许 david 这 个 用 户 在 任何 卫 段 
下 连接 该 实例 ， 并 且 不 需要 密码 。 此 外 ， 还 给 出 了 root 用 户 在 各 个 网 段 
下 的 访问 控制 权限 。 





15.2 命名 管道 和 共享 内 存 


在 Windows 2000、Windows XP. Windows 2003 和 Windows Vista 以 
及 在 此 之 上 的 平台 上 ， 如 果 两 个 需要 进程 通信 的 进程 在 同一 全 服务 器 
上 ， 那 么 可 以 使 用 命名 管道 ，Microsoft SQL Server 数 据 库 默 认 安 装 后 的 
本 地 连接 也 是 使 用 命名 管道 。 在 MySQL 数 据 库 中 须 在 配置 文件 中 启用 -- 
enable-named-pipe 选 项 。 在 MySQL 4.1 之 后 的 版 本 中 ，MySQL 还 提供 了 
共享 内 存 的 连接 方式 ， 这 是 通过 在 配置 文件 中 添加 --shared-memory 实 现 
的 。 如 果 想 使 用 共享 内 存 的 方式 ， 在 连接 时 ，MySQL 客 户 端 还 必须 使 
用 --protocol=memory 选 项 。 














1.553 UNIXOX&XE dE E 


在 Linux 和 UNIX 环 境 下 ， 还 可 以 使 用 UNIX 域 套 接 字 。UNIX 域 套 接 
字 其 实 不 是 一 个 网 络 协议 ， 所 以 只 能 在 MySQL 客 户 端 和 数据 库 实 例 在 
一 台 服 务 器 上 的 情况 下 使 用 。 用 户 可 以 在 配置 文件 中 指定 套 接 字 文件 的 
路 径 ， 如 --socket=/tmp/mysql.sock。 当 数据 库 实 例 启 动 后 ， 用 户 可 以 通 
过 下 列 命令 来 进行 UNIX 域 套 接 字 文件 的 查找 : 














Variable_name:socket 
Value:/tmp/mysql.sock 
1 row in set(0.00 sec) 





在 知道 JUNIX 域 套 接 字 文件 的 路 径 后 ， 就 可 以 使 用 该 方式 进行 连 
接 了 ， 如 下 所 示 : 





[root@stargazer ~ ]#mysql-udavid-S/tmp/mysql.sock 
Welcome to the MySQL monitor.Commands end with;or\g. 
Your MySQL connection id is 20333 

Server version:5.0.77-log MySQL Community Server (GPL) 
Type'help; 'or'\h'for help.Type'\c'to clear the buffer. 
mysql> 
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本 章 首 先 介 绍 了 数据 库 和 数据 库 实 例 的 定义 ， 紧 接着 分 析 了 
MySQL 数 据 库 的 体系 结构 ， 从 而 进一步 突出 强调 了 “实例 和“ 数据库” 的 
区 别 。 相 信 不 管 是 MySQL DBA 还 是 MySQL 的 开发 人 员 都 应 该 从 宏观 上 
了 解 了 MySQL 体 系 结构 ， 特 别 是 MySQL 独 有 的 插件 式 存储 引擎 的 概 
念 。 因 为 很 多 MySQL 用 户 很 少 意识 到 这 一 点 ， 这 给 他 们 的 管理 、 使 用 
和 开发 带 来 了 困扰 。 


本 章 还 详细 讲解 了 各 种 第 见 的 表 存 储 引 擎 的 特性 、 适 用 情况 以 及 它 
们 之 间 的 区 别 ， 以 便于 大 家 在 选择 存储 引擎 时 作为 参考 。 最 后 强调 一 
扩 ， 里 然 MySQL 有 许多 的 存储 引擎 ， 但 古 它们 之 间 不 存在 优 务 性 的 甘 
异 ， 用 户 应 根据 不 同 的 应 用 选择 适合 目 己 的 存储 引擎 。 当 然 ， 如 果 你 能 
力 很 强 ， 完 全 可 以 修改 存储 引擎 的 源 代码 ， 甚 至 是 创建 属于 上 自己 特定 应 
用 的 存储 引擎 ， 这 不 就 是 开源 的 魅力 吗 ? 








782:3 InnoDB fi 5| & 


InnoDB 是 事务 安全 的 MySQL 存 储 引 擎 ， 设 计 上 采用 了 类 似 于 Oracle 
数据 库 的 架构 。 通 常 来 说 ，InnoDB 存 储 引 擎 是 OLTP 应 用 中 核心 表 的 首 
选 存 储 引 擎 。 同 时 ， 也 正 是 因为 InnoDB 的 存在 ， 才 使 MySQL 数 据 库 变 
得 更 有 魅力 。 本 章 将 详细 介绍 InnoDB 存 储 引 擎 的 体系 架构 及 其 不 同 于 
其 他 存储 引擎 的 特性 。 


2.1 InnoDB 存 储 引 擎 概述 


InnoDB 存 储 引擎 最 早 由 Innobase Oy 公司 Js 开发， 被 包括 在 MySQL 数 
据 库 所 有 的 二 进 制 发 行 版 本 中 ， 从 MySQL 5.5 版 本 开始 是 默认 的 表 存 储 
引擎 〈 之 前 的 版 本 InnoDB 存 储 引 擎 仅 在 Windows 下 为 默认 的 存储 引 
8E) 。 该 存储 引擎 是 第 一 个 完整 文 持 ACID 事务 的 MySQL 存 储 引 擎 
(BDB 是 第 一 个 支持 事务 的 MySQL 存 储 引擎 ， 现 在 已 经 停止 开发 ) ， 
其 特点 是 行 锁 设计 、 文 持 MVCC、 支 持 外 键 、 提 供 一 致 性 非 锁 定 恋 ， 同 
时 被 设计 用 来 最 有 效 地 利用 以 及 使 用 内 存 和 CPU。 


Heikki Tuuri (1964 和 年， 芬兰 赫尔辛基 ) 是 InnoDB 存 储 引 擎 的 创始 
人 ， 和 著名 的 Linux 创 始 人 Linus 是 耸 兰 赫尔辛基 大 学 校友 。 在 1990 年 获 
得 赫 尔 六 基 大 学 的 数学 逻辑 博士 学 位 后 ， 他 于 1995 年 成 立 Innobase Oy 
司 并 担任 CEO。 同 时 ， 在 InnoDB 存 储 引 擎 的 开发 团队 中 ， 有 来 自 中 国 
科技 大 学 的 Calvin ”Sun。 而 最 近 又 有 一 个 中 国人 Jimmy Yang 也 加 入 了 
InnoDB 存 储 引擎 的 核心 开发 团队 ， 负 责 全 文 索引 的 开发 ， 其 之 前 任职 
于 Sybase 数据 库 公 司 ， 负 责 数据 库 的 相关 开发 工作 。 


InnoDB 存 储 引 擎 已 经 被 许多 大 型 网 站 使 用 ， 如 用 户 熟 知 的 Google、 
Yahoo!、Facebook、YouTube、Flickr， 在 网 络 游戏 领域 有 《魔兽 世 
界 》、《Second Life》、《 神 兵 芯 奇 》 等 。 我 不 是 MySQL 数 据 库 的 布道 
者 ， 也 不 是 mnoDB 的 鼓吹 者 ， 但 是 我 认为 当前 实施 一 个 新 的 OLTP 项 目 
不 使 用 MySQL InnoDB 存 储 引 擎 将 是 多 么 的 愚蠢 。 


从 MySQL 数 据 库 的 官方 手册 可 得 知 ， 著 名 的 Internet 新 闻 站 点 
Slashdot.org 运 行 在 InnoDB 上 。Mytrix、Inc. 在 InnoDB 上 存储 超过 1 TB 的 
数据 ， 还 有 一 些 其 他 站 点 在 mnoDB 上 处 理 插入 /更 新 操作 的 速度 平均 为 
800 次 / 秒 。 这 些 都 证 明了 InnoDB 是 一 个 高 性 能 、 高 可 用 、 高 可 扩展 的 存 
fit 5| SE. 

InnoDB 存 储 引 敬 同 MySQL 数 据 库 一 样 ， 在 GNU GPL 2 下 发 行 。 更 
多 有 关 MySQL 证 书 的 信息 ， 可 参考 http://www.mysql.com/about/legal/， 

这 里 不 再 详细 介绍 。 


[112006 年 该 公司 已 经 被 Oracle 公 司 收 购 。 














2.2 ”InnoDB 存 储 引 擎 的 版 本 


InnoDB 存 储 引 擎 被 包含 于 所 有 MySQL 数 据 库 的 二 进 制 发 行 版 本 
中 。 早 期 其 版 本 随 独 MySQL 数 据 库 的 更 新 而 更 新 。 从 MySQL ”5.1 版 本 
时 ，MySQL 数 据 库 允许 存储 引擎 开发 商 以 动态 方式 加 载 引 擎 ， 这 样 存 
储 引 擎 的 更 新 可 以 不 受 MySQL 数 据 库 厂 本 的 限制 。 所 以 在 MYSQL 5.1 
中 ， 可 以 支持 两 个 版 本 的 InnoDB， 一 个 是 静态 编译 的 InnoDB 版 本 ， 可 
将 其 视 为 老 版 本 的 InnoDB; 另 一 个 是 动态 加 载 的 mnoDB 版 本 ， 官 方 称 
为 InnoDB Plugin， 可 将 其 视 为 IhnoDB 1.0.x 版 本 。MySQL 5.5 版 本 中 又 
将 InnoDB 的 版 本 升级 到 了 1.1.x。 而 在 最 近 的 MySQL ”5.6 版 本 中 InnoDB 
表 2-1 显 示 了 各 个 版 本 中 InnoDB 存 储 引 
擎 的 功能 








824 Imo EROR 


io ) & 
AE InnoDB 3 ACID, frt, MVCC 


ImoDB | ART EENAA DE, T compress 和 和 dynanic A 
JoDB Lx d T aint, HMT Lim AO, ZR 
Imo8 [x EAR DSTI E COP FARIEN 











在 现实 工作 中 我 发 现 很 多 MYSQL 数据 库 还 是 停留 在 MySQL — 5.1 
本 ， 并 使 用 mnoDB Plugin。 很 多 DBA 错 误 地 认为 InhnoDB ” Plugin 和 





InnoDB 1.1 版 本 之 间 是 没有 区 别 的 。 但 从 表 2-1 中 还 是 可 以 发 现 ， 虽 然 都 
增加 了 对 于 compress 和 dynamic 页 的 支持 ， 但 是 ImnoDB Plugin 是 不 支持 
Linux Native AIO 功 能 的 。 此 外 ， 由 于 不 文 持 多 回 深 段 ，InnoDB Plugin 
支持 的 最 大 文 持 并 发 事务 数量 也 被 限制 在 1023。 而 且 随 着 MySQL 5.5 版 
KRH, InnoDB Plugin 也 变 成 了 一 个 历史 产品 。 


2.3 JInnoDB 体 系 架 构 


通过 第 1 章 读者 已 经 了 解 了 MySQL 数 据 库 的 体系 结构 ， 现 在 可 能 想 
更 深入 地 了 解 InnoDB 存 储 引擎 的 架构 。 图 2-1 简 单 显 示 了 InnoDB 的 存储 
引擎 的 体系 架构 ， 从 图 可 见 ，InnoDB 存 储 引 擎 有 多 个 内 存 块 ， 可 以 认 
为 这 些 内 存 块 组 成 了 一 个 大 的 内 存 池 ， 人 负责 如 下 工作 : 


口 维护 所 有 进程 /线程 需要 访问 的 多 个 内 部 数据 结构 。 

















口 缓存 磁盘 上 的 数据 ， 方 便 快 速 地 读 取 ， 同 时 在 对 磁盘 文件 的 数据 
修改 之 前 在 这 里 缓存 。 


口 重 做 日 志 Credo log) R. 


InnoDB RE RE EAE 





图 2-1 InoDB 存 储 引 擎 体系 架构 


后 人 台 线 程 的 主要 作用 是 负责 刷新 内 存 池 中 的 数据 ， 保 证 缓冲 池 中 的 
内 存 缓存 的 是 最 近 的 数据 。 此 外 将 已 修改 的 数据 文件 刷新 到 磁盘 文件 ， 
同时 保证 在 数据 库 发 生 异 常 的 情况 下 InnoDB 能 恢复 到 正常 运行 状态 。 


2.3.1 ”后台 线程 


InnoDB 和 存储 引擎 是 多 线程 的 模型 ， 因 此 其 后 全 有 多 个 不 同 的 后 台 
线程 ， 负 责 处 理 不 同 的 任务 。 


1.Master Thread 


Master Thread 是 一 个 非常 核心 的 后 台 线 程 ， 主 要 负责 将 缓冲 池 中 的 
数据 异步 刷新 到 磁盘 ， 保 证 数据 的 一 至 性， 包括 脏 页 的 刷新 、 合 并 插入 
缓冲 (INSERT BUFFER) 、UNDO 页 的 回收 等 。2.5 节 会 详细 地 介绍 各 
个 版 本 中 Master Thread 的 工作 方式 。 


2.IO Thread 


在 InnoDB 存 储 引擎 中 大 量 使 用 了 AIO (Async 10) 来 处 理 写 IO 请 
求 ， 这 样 可 以 极 大 提高 数据 库 的 性 能 。 而 IO Thread 的 工作 主要 是 负责 这 
些 IO 请 求 的 回调 (call back) 处 理 。InnoDB ”1.0 版 本 之 前 共有 4 个 IO 
Thread， 分 别 是 write、read、insert bufferflllog IO thread。 在 Linux 平 台 
F, IO Thread 的 数量 不 能 进行 调整 ， 但 是 在 Windows 平 台 下 可 以 通过 参 
数 innodb file io threads 来 增 大 IO Thread。 从 InnoDB 1.0.x 版 本 开始 ， 
read thread 和 write thread 分 别 增 大 到 了 4 个 ， 并 且 不 再 使 用 
innodb_file_io_threads 参 数 ， 而 是 分 别 使 用 innodb_read_io_threads 和 
innodb_write_io_threads 参 数 进行 设置 ， 如 : 




















mysql>SHOW VARIABLES LIKE'innodb_version'\G; 


ORO OR OR KO KO ORO GO ROGO GGG] py RR RR Re e eR IOI e I e ek 


Value:1.0.6 
1 ro et(0.00 sec) 
mysql1- SHOW VARIABLES LIKE'innodb_%io_threads'\G; 


AORGOKO ORO ORO IO ROGO ORO ROGO RO] c py CRGO RR RR KO ROO ROIG KO ROG RO 


OR KO ICICI IOI ICICI ICICI. pe CROCO RR RO ROO ROO ROIG KO ROO RO 


2 rows in set(0.00 sec) 





可 以 通过 命令 SHOW ENGINE INNODB STATUS 来 观察 InnoDB 中 
的 IO Thread: 





mysql1- SHOW ENGINE INNODB STATUS\G; 
ORDIOOOEOOOOIOOIOOOIOOIODIEOOROOIOOEEL | p CROOORIOROOOOOROROIOOIOOIOROROROROIGIOEOEK 
Type:InnoDB 

Name : 

Status: 


I/O thread 9 state:waiting for i/o request(insert buffer thread) 
I/O thread 1 state:waiting for i/o request(log thread) 

I/O thread 2 state:waiting for i/o request(read thread) 

I/O thread 3 state:waiting for i/o request(read thread) 

I/O thread 4 state:waiting for i/o request(read thread) 

I/O thread 5 state:waiting for i/o request(read thread) 

I/O thread 6 state:waiting for i/o request(write thread) 

I/O thread 7 state:waiting for i/o request(write thread) 

I/O thread 8 state:waiting for i/o request(write thread) 

I/O thread 9 state:waiting for i/o request(write thread) 


1 row in set(0.01 sec) 





可 以 看 到 IO Thread 0 为 insert buffer thread. IO Thread 1 为 log 
thread。 之 后 就 是 根据 参数 innodb_read_io_threads 及 
innodb_write io_threads 来 设置 的 读 写 线程 ， 并 且 读 线程 的 ID 总 是 小 于 写 
线程 。 


3.Purge Thread 


事务 被 提交 后 ， 其 所 使 用 的 undolog 可 能 不 再 需要 ， 因 此 需要 
PurgeThread 来 回收 已 经 使 用 并 分 配 的 undo 页 。 在 InnoDB 1.1 版 本 之 前 ， 
purge 操 作 仅 在 InnoDB 存 储 引 擎 的 Master Thread 中 完成 。 而 从 InnoDB 1.1 
版 本 开始 ，purge 操 作 可 以 独立 到 单独 的 线程 中 进行 ， 以 此 来 减轻 Master 
Thread 的 工作 ， 从 而 提高 CPU 的 使 用 率 以 及 提升 存储 引擎 的 性 能 。 用 户 
可 以 在 MySQL 数 据 库 的 配置 文件 中 添加 如 下 命令 来 启用 独立 的 Purge 
Thread: 











[mysqld] 
innodb_purge_threads=1 





在 InnoDB 1.1 版 本 中 ， 即 使 将 innodb_purge_threads 设 为 大 于 1， 
mu Ms 引擎 启动 时 也 会 将 其 设 为 1， 并 在 错误 文件 中 出 现 如 下 类 似 
J 提示: 





120529 22:54:16[Warning]option'innodb-purge-threads':unsigned value 4 adjusted to 1 





从 InnoDB 1.2 版 本 开始 ，InnoDB 支 持 多 个 Purge Thread， 这 样 做 的 


目的 是 为 了 进一步 加 快 undo 页 的 回收 。 同 时 由 于 Purge Thread 需 要 离散 
地 读 取 undo 页 ， 这 样 也 能 更 进一步 利用 磁盘 的 随机 读 取 性 能 。 如 用 户 可 
以 设置 4 个 Purge Thread: 





mysql>SELECT VERSION()\G; 


VERSION():5.6.6 

1 row in set(0.00 sec) 

mysql>SHOW VARIABLES LIKE'innodb purge threads'*G; 

FOR II IOI IOI ITO ITO TO II I a 4. FOW* ISI ICI I I I III AOR 
Variable name:innodb purge thr 
Value:4 

1 row in set(0.00 sec) 


ow 
eads 





4.Page Cleaner Thread 


Page Cleaner Thread 是 在 InnoDB 1.2.x 版 本 中 引入 的 。 其 作用 是 将 之 
前 版 本 中 脏 页 的 刷新 操作 都 放 入 到 单独 的 线程 中 来 完成 。 而 其 目的 是 为 
了 减轻 原 Master Thread 的 工作 及 对 于 用 户 查 询 线 程 的 阻塞 ， 进 一 步 提 高 
InnoDB 存 储 引 擎 的 性 能 。 





2.3.2 内存 
1.28 hr 


InnoDB 存 储 引 擎 是 基于 破 盘 存储 的 ， 并 将 其 中 的 记录 按照 页 的 方 
式 进 行 管理 。 因 此 可 将 其 视 为 基于 磁盘 的 数据 库 系 统 〈Disk-base 
Database) 。 在 数据 库 系统 中 ， 由 于 CPU 速度 与 磁盘 速度 之 间 的 鸿沟 ， 
基于 人 破 盘 的 数据 库 系 统 通常 使 用 缓冲 池 技 术 来 提高 数据 库 的 整体 性 能 。 


绥 冲 池 简 单 来 说 就 是 一 块 内 存 区 域 ， 通 过 内 存 的 速度 来 弥补 磁盘 速 
度 较 慢 对 数据 库 性 能 的 影响 。 在 数据 库 中 进行 读 取 页 的 操作 ， 首 先 将 从 
磁盘 读 到 的 页 存放 在 绥 冲 池 中 ， 这 个 过 程 称 为 将 页 “FIX” 在 缓冲 池 中 。 

下 一 次 再 读 相同 的 页 时 ， 首 先 判 断 该 页 是 否 在 缓冲 池 中 。 阁 在 缓冲 池 
称 该 页 在 缓冲 池 中 被 命中 ， 直 接 读 取 该 页 。 否 则 ， 读 取 磁 盘 上 的 




















中 ， 
页 。 
对 于 数据 库 中 页 的 修改 操作 ， 则 首先 修改 在 缓冲 池 中 的 页 ， 然 后 再 
以 一 定 的 频率 刷新 到 磁盘 上 。 这 里 需要 注意 的 是 ， 页 从 缓冲 池 刷 新 回 破 
盘 的 操作 并 不 是 在 每 次 页 发 生 更 新 时 触及， 而 是 通过 一 种 称 关 
Checkpoint 的 机 制 刷 新 加 磁盘 。 同 样 ， 这 也 是 为 了 提 融 数据 库 的 整体 性 


已 
HE o 
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操作 系统 的 限制 ， 在 该 系统 下 最 多 将 该 值 设 置 为 3G。 此 外 用 户 可 以 打 
开 操作 系统 的 PAE 选 项 来 获得 32 位 操作 系统 下 最 大 64GB 内 存 的 文 持 。 
随 着 内 存 技术 的 不 断 成 熟 ， 其 成 本 也 在 不 断 下 降 。 单 条 8GB 的 内 存 变 得 
非常 普遍 ， 而 PC 服务 器 已 经 能 支持 512GB 的 内 存 。 因 此 为 了 让 数据 库 使 
用 更 多 的 内 存 ， 强 烈 建议 数据 库 服务 器 都 采用 64 位 的 操作 系统 。 


对 于 InnoDB 存 储 引 擎 而 言 ， 其 缓冲 池 的 配置 通过 参数 
innodb buffer pool_size 来 设置 。 下 面 显 示 一 台 MySQL 数 据 库 服务 器 ， 
其 将 InnoDB 存 储 引 擎 的 缓冲 池 设 置 为 15GB。 





mysql>SHOW VARIABLES LIKE'innodb buffer pool size'*G6; 
FOI TO TOTO TOIT TO IO I IC OW? BRR RR RK k 
Variable name:innodb buffer pool size 
Value:16106127360 

1 row in se 


t(0.00 sec) 





具体 来 看 ， 组 冲 池 中 缓存 的 数据 页 类 型 有 : RIR HHR, undo 
页 、 插 入 缓冲 Cinsert buffer) 、 目 适应 哈 希 索引 (adaptive hash 
index) 、InnoDB 存 储 的 锁 信 息 Clock info) 、 数 据 字 上 典 信息 (data 
dictionary) 等 。 不 能 简单 地 认为 ， 绥 冲 池 只 是 缓存 索引 页 和 数据 页 ， 它 
们 只 是 占 缓冲 池 很 大 的 一 部 分 而 已 。 图 2-2 很 好 地 显示 了 InnoDB 存 储 引 
擎 中 内 存 的 结构 情况 。 








FMM (innodb buffer pool) 
ARREA UM 


(redo log buffer) 


il E ) 
AGH Ganee) U a |) ge 
(insert buffer) | | (lock info) 


SNR 


(innodb additional 
mem pool size) 


索引 页 (index page) 





图 2-2 InnoDB 内 存 数 据 对 象 


从 InnoDB 1.0.x 版 本 开始 ， 人 允许 有 多 个 绥 冲 池 实 例 。 每 个 页 根据 哈 
希 值 平均 分 配 到 不 同 缓冲 池 实 例 中 。 这 样 做 的 好 处 是 减少 数据 库 内 部 的 
资源 竞争 ， 增 加 数据 库 的 并 发 处 理 能 力 。 可 以 通过 参数 
innodb buffer pool _instances 来 进行 配置 ， 该 值 默认 为 1。 





mysql1- SHOW VARIABLES LIKE'innodb buffer pool instances'*G; 
JOOOOOOOOOOOOOOOOOOOOIOOOOOOR] I p yy FA ICICI I ISI I III IIIA II IE 
Variable name:innodb buffer pool instances 

Value:1 

1 row in set(0.00 sec) 





在 配置 文件 中 将 innodb_- - pool, instancesi EL 73 X T 185) [EUG HT 
以 得 到 多 个 缓冲 池 实 例 。 再 通过 命令 SHOW ENGINE INNODB STATUS 
可 以 观察 到 如 下 的 内 容 : 





mysql- SHOW ENGINE INNODB STATUS\G; 


ORO OK ROO KO ROI ROO ROG EO Gee] py ek e e ek eR ke Re e ee 


Type:InnoDB 


--BUFFER POOL 0 
Buffer pool size 65535 
Free buffers 65451 
Database pages 84 
Old database pages 0 
Modified db pages 0 
Pending reads 0 
Pending writes:LRU O,flush list © single page 0 
Pages made young 0,not young 0 
0.00 youngs/s,0.00 non-youngs/s 
Pages read 84,created O,written 1 
9.33 reads/s,0.00 creates/s,0.11 writes/s 
Buffer pool hit rate 764/1000, young-making rate 0/1000 not 0/1000 
Pages read ahead 0.00/s,evicted without access 0.00/s,Random read ahead 0.00/s 
LRU len:84,unzip LRU len:0 
I/O sum[0]:cur[0],unzip sum[0]:cur[0] 
--BUFFER POOL 1 
Buffer pool size 65536 
Free buffers 65473 
Database pages 63 
Old database pages 0 
Modified db pages 0 
Pending reads 0 
Pending writes:LRU O,flush list © single page 0 
Pages made young 0,not young 0 
0.00 youngs/s,0.00 non-youngs/s 
Pages read 63,created O,written O 
7.00 reads/s,0.00 creates/s,0.00 writes/s 
Buffer pool hit rate 500/1000, young-making rate 0/1000 not 0/1000 
Pages read ahead 0.00/s,evicted without access 0.00/s,Random read ahead 0.00/s 
LRU len:63,unzip LRU len:0 
I/O sum[0]:cur[0],unzip sum[0]:cur[0] 





这 DL ion NS 2， 即 数据 库 用 户 拥 
有 两 个 缓冲 池 实 例 。 通 过 命令 SHOW ENGINE INNODB STATUS 可 以 观 
察 到 每 个 缓冲 池 实 例 对 象 运行 的 状态 ， 并 且 通 过 类 似 ---BUFFER POOL 
0 的 注释 来 表明 是 哪个 组 神 池 实例 。 


从 MySQL 5.6 版 本 开始 ， 还 可 以 通过 information_ porc 
INNODB_BUEFFER_POOL_STATS 来 观察 缓冲 的 状态 ， 如 运行 下 列 命 
可 以 看 到 各 个 绥 冲 池 的 使 用 状态 : 








mysql>SELECT POOL. ID,POOL. SIZE, 

- >FREE_BUFFERS, DATABASE. PAGES 

->FROM INNODB BUFFER POOL. STATSNG; 
REEERRRKRRREEERERRRRRARRXEER] pQuFT COGOR ARRAROOOOOOOR OR UGG 
POOL. ID:0O 

POOL. SIZE:65535 


FREE_BUFFERS: 65451 
DATABASE PAGES:84 


FREE. BUFFERS:65473 
DATABASE PAGES:63 





2.LRU List. Free Listfll Flush List 


在 前 一 小 节 中 我 们 知道 了 缓冲 池 是 一 个 很 大 的 内 存 区 域 ， 其 中 存放 
各 种 类 型 的 页 。 那 么 mnoDB 存 储 引 擎 是 怎么 对 这 么 大 的 内 存 区 域 进 行 
管理 的 呢 ? 这 就 是 本 小 节 要 告诉 读者 的 。 


通常 来 说 ， 数 据 库 中 的 绥 冲 池 是 通过 LRU (Latest Recent Used， 最 
近 最 少 使 用 ) 算法 来 进行 管理 的 。 即 最 频繁 使 用 的 页 在 LRU 列 表 的 前 
， 而 最 少 使 用 的 页 在 LRU 列 表 的 尾 端 。 当 缓冲 池 不 能 存放 新 读 取 到 的 
页 时 ， 将 首先 释放 LRU 列 表 中 尾 端 的 页 。 


在 InnoDB 存 储 引 擎 中 ， 绥 冲 池 中 页 的 大 小 默认 为 16KB， 同 样 使 用 
LRU 算 法 对 缓冲 池 进 行 管理 。 稍 有 不 同 的 是 mnoDB 存 储 引 擎 对 传统 的 
LRU 算 法 做 了 一 些 优化 。 在 InnoDB 的 存储 引擎 中 ，LRU 列 表 中 还 加 入 
了 midpoint 位 置 。 新 读 取 到 的 页 ， 虽 然 是 最 新 访问 的 页 ， 但 并 不 是 直接 
放 入 到 LRU 列 表 的 首部 ， 而 是 放 入 到 LRU 列 表 的 midpoint 位 置 。 这 个 算 
法 在 InnoDB 存 储 引 擎 下 称 为 midpoint insertion strategy。 在 默认 配置 下 ， 
该 位 置 在 LRU 列 表 长 度 的 5/8 处 。midpoint 位 置 可 由 参数 
innodb_old_blocks_pct 控 制 ， 如 ; 














zelo. 











mysql>SHOW VARIABLES LIKE'innodb old blocks pct'*6; 
ETE 


Vi able name:innodb old blocks pct 


rà 
in set(0.00 sec) 





从 上 面 的 例子 可 以 看 到 ， 参 数 innodb_old_blocks_pct 默 认 值 为 37， 
表示 新 读 取 的 页 插入 到 LRU 列 表 尾 端的 37% 的 位 置 ( 差 不 多 3/8 的 位 
置 ) 。 在 InnoDB 存 储 引 擎 中 ， 把 midpoint 之 后 的 列表 称 为 old 列 表 ， 之 前 
Bac 可 以 简单 地 理解 为 new 列 表 中 的 页 都 是 最 为 活跃 


那 为 什么 不 采用 朴素 的 LRU 算 法 ， 直 接 将 读 取 的 页 放 入 到 LRU 列 表 
的 首部 呢 ?” 这 是 因为 石 直接 将 读 取 到 的 页 放 入 到 LRU 的 首部 ， 那 么 某 些 
SQL 操 作 可 能 会 使 缓冲 池 中 的 页 被 刷新 出 ， 从 而 影响 缓冲 池 的 效率 。 常 


见 的 这 类 操作 为 索引 或 数据 的 扫 摘 操作 。 这 类 操作 需要 访问 表 中 的 许多 
页 ， 其 至 是 全 部 的 页 ， 而 这 些 页 通常 来 说 又 仪 在 这 次 查询 操作 中 需要 ， 
并 不 是 活跃 的 热点 数据 。 如 果 页 被 放 入 LRU 列 表 的 首部 ， 那 么 非常 可 能 
将 所 需要 的 热点 数据 页 从 LRU 列 表 中 移 除 ， 而 在 下 一 次 需要 读 取 该 页 
时 ，InnoDB 存 储 引 擎 需要 再 次 访问 破 盘 。 


为 了 解决 这 个 问题 ，InnoDB 存 储 引 擎 引入 了 男 一 个 参数 来 进一步 
管理 LRU 列 表 ， 这 个 参数 是 innodb_old_blocks_time， 用 于 表示 页 读 取 到 
mid 位 置 后 需要 等 待 多 久 才 会 被 加 入 到 LRU 列 表 的 热 端 。 因 此 当 需 要 执 
行 上 述 所 说 的 SQL 操 作 时 ， 可 以 通过 下 面 的 方法 尽 可 能 使 LRU 列 表 中 热 
点 数据 不 被 刷 出 。 























mysql>SET GLOBAL innodb old blocks time=1000; 
Query OK,0 rows affected(0.00 sec) 
4data or index s operation 


mysql>SET GLOBAL innodb old blocks. time-6; 
Query OK,0 rows affected(0.00 sec) 
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前 ， 还 可 以 通过 下 面 的 语句 来 减少 热点 页 可 能 被 刷 出 的 概率 。 





mysql>SET GLOBAL innodb old blocks pct-20; 
Query OK,0 rows affected(0.00 sec) 





LRU 列 表 用 来 管理 已 经 读 取 的 页 ， 但 当 数 据 库 刚 启动 时 ，LRU 列 表 
是 空 的 ， 即 没有 任何 的 页 。 这 时 页 都 存放 在 Free 列 表 中 。 当 需要 从 缓冲 
池 中 分 页 时 ， 首 先 从 Free 列 表 中 查找 是 否 有 可 用 的 空闲 页 ， 若 有 则 将 该 
页 从 Free 列 表 中 删除 ， 放 入 到 LRU 列 表 中 。 和 否则 ， 根 据 LRU 算 法 ， 淘 汰 
LRU 列 表 末 尾 的 页 ， 将 该 内 存 空 间 分 配给 新 的 页 。 当 页 从 LRU 列 表 的 
old 部 分 加 入 到 new 部 分 时 ， 称 此 时 发 生 的 操作 为 page made young， 而 因 
Zjinnodb old blocks time 的 设置 而 导致 页 没有 从 old 部 分 移动 到 new 部 分 
的 操作 称 为 page not made young。 可 以 通过 命令 SHOW ENGINE 
INNODB STATUS 来 观察 LRU 列 表 及 Free 列 表 的 使 用 情况 和 运行 状态 。 























mysql- SHOW ENGINE INNODB STATUS\G; 
ORDIOOOOOEOOIOOIOOOEOROIOOIOOOOOIOUEEA | POŠ KRKK R KK KKR R KK KKK K KKK 


Per second averages calculated from the last 24 seconds 


Buffer pool size 327679 
Free buffers 0 
Database pages 307717 


Old database pages 113570 

Modified db pages 24673 

Pending reads 0 

Pending writes:LRU O,flush list 0,single page 0 

Pages made young 6448526,not young 0 

48.75 youngs/s,0.00 non-youngs/s 

Pages read 5354420,created 239625,written 3486063 

55.68 reads/s,81.74 creates/s,955.88 writes/s 

Buffer pool hit rate 1000/1000, young-making rate 0/1000 not 0/1000 





通过 命令 SHOW ENGINE INNODB STATUS 可 以 看 到 : 当前 Buffer 
pool size 共 有 327 ”679 个 页 ， 即 327679*16K， 总 共 5GB 的 缓冲 池 。Free 
buffers 表 示 当 前 Free 列 表 中 页 的 数量 ，Database pages 表 示 LRU 列 表 中 页 
的 数量 。 可 能 的 情况 是 Free buffers 与 Database pages 的 数量 之 和 不 等 于 
Buffer pool size。 正 如 图 2-2 所 示 的 那样 ， 因 为 缓冲 池 中 的 页 还 可 能 会 被 
分 配给 自 适 应 哈 希 索 引 、Lock 信 息 、Insert Buffer 等 页 ， 而 这 部 分 页 不 需 
要 LRU 算 法 进行 维护 ， 因 此 不 存在 于 LRU 列 表 中 。 


pages made young 显 示 了 LRU 列 表 中 页 移动 到 前 端的 次 数 ， 因 为 该 
服务 器 在 运行 阶段 没有 改变 innodb_old_blocks_time 的 值 ， 因 此 not young 
为 0。youngs/s、non-youngs/s 表 示 每 秒 这 两 类 操作 的 次 数 。 这 里 还 有 一 
个 重要 的 观察 变量 Buffer pool hit rate， 表 示 绥 冲 池 的 命中 率 ， 这 个 
例子 中 为 100%， 说 明 缓 冲 池 运 行 状态 非常 民 好 。 通 常 该 值 不 应 该 小 于 
95%。 若 发 生 Buffer pool hit rate 的 值 小 于 95% 这 种 情况 ， 用 户 需 要 观察 
是 否 是 由 于 全 表 扫 描 引 起 的 LRU 列 表 被 污染 的 问题 。 


注意 ”执行 命令 SHOW ENGINE INNODB STATUS 显示 的 不 是 当前 
的 状态 ， 而 是 过 去 某 个 时 间 范 围 内 InnoDB 存 储 引 擎 的 状态 。 从 上 面 的 
例子 可 以 发 现 ，Per second averages calculated from the last 24 seconds 代 
表 的 信息 为 过 去 24 秒 内 的 数据 库 状 态 。 


从 InnoDB 1.2 版 本 开始 ， 还 可 以 通过 表 
INNODB BUFFER POOL STATS 来 观察 缓冲 池 的 运行 状态 ， 如 ; 























mysql>SELECT POOL ID,HIT RATE, 
-— PAGES MADE YOUNG, PAGES_NOT_MADE_YOUNG 
->FROM information schema.INNODB BUFFER POOL STATS*G; 


POOL ID:O 

HIT RATE: 980 

PAGES MADE YOUNG:450 
PAGES NOT MADE YOUNG:O 





此 外 ， 还 可 以 通过 表 INNODB BUFFER PAGE _LRU 来 观察 每 个 
LRU 列 表 中 每 个 页 的 具体 信息 ， 例 如 通过 下 面 的 语句 可 以 看 到 缓冲 池 
LRU 列 表 中 SPACE 为 1 的 表 的 页 类 型 : 








mysql- SELECT TABLE NAME, SPACE, PAGE NUMBER, PAGE TYPE 
- >FROM E BUFFER | Ie LRU WHERE SPACE-1; 


Wee-teweostetpReeerd-r b ueeeUeeTuurhesceeuedeepU eA 


DOE cd ICE NONSE ONE NEM C RC E EC ERE E 
NU [ORE TEE: SPACE. HEADER] 

|NULL|1|1|IBUF BITMAP | 

|NULL | 1| 2 | INODE | 

1test/t14131INDEX| 

ee E E a E EEEE EE E AED 


4 rows in Seto 00 Hes 





InnoDB 存 储 引 擎 从 1.0.x 版 本 开始 文 持 压缩 页 的 功能 ， 即 将 原本 
16KB 的 页 压缩 为 IKB、2KB、4KB 和 8KB。 而 由 于 页 的 大 小 发 生 了 变 
化 ， LRU 列 表 也 有 了 些许 的 改变 。 对 于 非 16KB 的 页 ， 是 通过 unzip_LRU 
列表 进行 管理 的 。 通 过 命令 SHOW ENGINE INNODB STATUS 可 以 观察 
到 如 下 内 容 ; 








mysql- SHOW ENGINE INNODB STATUS\G; 


Buffer pool hit rate 999/1000, young-making rate 0/1000 not 0/1000 

Pages read ahead 0.00/s,evicted without access 0.00/s,Random read ahead 0.00/s 
LRU len:1539,unzip LRU len:156 

I/O sum[0]:cur[0],unzip sum[0]:cur[0] 





可 以 看 到 LRU 列 表 中 一 共有 1539 个 页 ， 而 unzip_LRU 列 表 中 有 156 
个 页 。 这 里 需要 注意 的 是 ，LRU 中 的 页 包含 了 unzip_LRU 列 表 中 的 页 。 


对 于 压缩 页 的 表 ， 每 个 表 的 压缩 比率 可 能 各 不 相同 。 可 能 存在 有 的 
表 页 大 小 为 8KB， 有 的 表 页 大 小 为 2KB 的 情况 。 unzip, LRU 是 怎样 从 组 
冲 池 中 分 配 内 存 的 呢 ? 

首先 ， 在 unzip_LRU 列 表 中 对 不 同 压缩 页 大 小 的 页 进行 分 别管 
其 次 ， 通 过 伙伴 算法 进行 内 存 的 分 配 。 例 如 对 需要 从 缓冲 池 中 申 i sare 
4KB 的 大 小 ， 其 过 程 如 下 : 

1) 检查 4KB 的 unzip_LRU 列 表 ， 检 查 是 否 有 可 用 的 空间 页 ; 

2) BA, WARMER: 


3) 否则 ， 检 查 8KB 的 unzip_LRU 列 表 ; 














4) 知 能 够 得 到 空闲 页 ， 将 页 分 成 2 个 4KB 页 ， 存 放 到 4KB 的 
unzip_LRU 列 表 ; 


5) 车 不 能 得 到 空 亲 页， 从 LRU 列 表 中 申请 一 个 16KB 的 页 ， 将 页 分 


为 1 个 8KB 的 页 、2 个 4KB 的 页 ， 分 别 存放 到 对 应 的 unzip_LRU 列 表 中 。 


同样 可 以 通过 information_schema 架 构 下 的 表 
INNODB_BUFFER_PAGE_LRU 来 观察 unzip_LRU 列 表 中 的 页 ， 如 : 





mysql>SELECT 

- >TABLE_NAME, SPACE, PAGE_NUMBER, COMPRESSED_ SIZE 
- >FROM INNODB_BUFFER_PAGE_LRU 
- >WHERE COMPRESSED = STRES ZO; 


EEE T E E ME 


PE E E E E AE 
[obese Li ne 2 

|sbtest/t|9|135|8192| 

|sbtest/t|9|96|8192]| 

|sbtest/t|9|136|8192| 

|sbtest/t|9|32|8192]| 

|sbtest/t|9|97|8192| 

|sbtest/t|9|137|8192| 

|sbtest/t|9|98|8192| 





在 LRU 列 表 中 的 页 被 修改 后 ， 称 该 页 为 脏 页 (dirty page) ， 即 缓冲 
池 中 的 页 和 磁盘 上 的 页 的 数据 产生 了 不 一 致 。 这 时 数据 库 会 通过 
CHECKPOINT 机 制 将 脏 页 刷新 回 磁盘 ， 而 Flush 列 表 中 的 页 即 为 脏 页 列 
表 。 需 要 注意 的 是 ， 脏 页 既 存在 于 LRU 列 表 中 ， 也 存在 于 Flush 列 表 
中 。LRU 列 表 用 来 管理 缓冲 池 中 页 的 可 用 性 ，Flush 列 表 用 来 管理 将 页 
刷新 回 磁盘 ， 二 者 互 不 影响 。 


同 LRU 列 表 一 样 ，Flush 列 表 也 可 以 通过 命令 SHOW ENGINE 
INNODB STATUS 来 查看 ， 前 面 例子 中 Modified db pages 246733 Ss f 
及 页 的 数量 。information_schema 架 构 下 并 没有 类 似 
INNODB BUFFER PAGE _LRU 的 表 来 显示 脏 页 的 数量 及 脏 页 的 类 型 ， 
但 正如 前 面 所 述 的 那样 ， 脏 页 同样 存在 于 LRU 列 表 中 ， 故 用 户 可 以 通过 
元 数据 表 INNODB BUFFER, PAGE _LRU 来 查看 ， 唯 一 不 同 的 是 需要 加 
入 OLDEST_MODIFICATION 大 于 0 的 SQL 查询 条 件 ， 如 : 

















mysql>SELECT TABLE NAME, SPACE, PAGE NUMBER, PAGE TYPE 
- >FROM INNODB BUFFER PAGE LRU 
- >WHERE niri MORNE Ne 


证 和 


hee he Meme actos ee th he en E 
I Ee vee 

|NULL|O|O|FILE SPACE HEADER| 

|test/t|1|3|INDEX| 

| NULL | @|320 | INODE | 

| NULL | @|325|UNDO_LOG | 

Pesce sees Ap He A NR NE sessed 
5 rows in set(0.00 sec) 








可 以 看 到 当前 共有 5 个 脏 页 及 它们 对 应 的 表 和 页 的 类 型 。 
TABLE NAME 为 NULL 表 示 该 页 属于 系统 表 空 间 。 








3. A A 


从 图 2-2 可 以 看 到 ，InnoDB 存 储 引 警 的 内 存 区 域 除 了 有 缓冲 池 外 ， 
还 有 重 做 日 志 缓冲 (edo log buffer) 。InnoDB 存 储 引擎 首先 将 重 做 日 
志 信 息 先 放 入 到 这 个 缓冲 区 ， 然 后 按 一 定 频 率 将 其 刷新 到 重 做 日 志文 
件 。 重 做 日 志 绥 冲 一 般 不 需要 设置 得 很 大 ， 因 为 一 般 情 况 下 每 一 秒 钟 会 
将 重 做 日 志 组 冲刷 新 到 日 志文 件 ， 因 此 用 户 只 需要 保证 每 秒 产生 的 事务 
量 在 这 个 缓冲 大 小 之 内 即 可 。 该 值 可 由 配置 参数 innodb_log_buffer_size 
控制 ， 默 认为 8MB: 








mysql>SHOW VARIABLES LIKE'innodb_log_buffer_size'\G; 

OOROROR ORO ORG GIOI GIO OR OR] pO E TORO OI KE K KAE KE K I I I I I I a a eee 
Variable name:inno 
Value:8388608 

1 row in se 


t(0.00 sec) 





在 通常 情况 下 ，8MB 的 重 做 日 志 组 冲 池 足以 满足 绝 大 部 分 的 应 用 ， 
因为 重 做 日 志 在 下 列 三 种 情况 下 会 将 重 做 日 志 绥 冲 中 的 内 容 刷新 到 外 部 
磁盘 的 重 做 日 志文 件 中 。 


Q Master Thread 每 一 秒 将 重 做 日 志 绥 冲刷 新 到 重 做 日 志文 件 ; 
口 每 个 事务 提交 时 会 将 重 做 日 志 绥 冲刷 新 到 重 做 日 志文 件 ; 


口 当 重 做 日 志 绥 冲 池 剩余 空间 小 于 1/2 时 ， 重 做 日 志 绥 冲刷 新 到 重 
做 日 志文 件 。 


4. 额 外 的 内 存 池 


额外 的 内 存 池 通常 被 DBA 忽 略 ， 他 们 认为 该 值 并 不 十 分 重要 ， 事 实 
恰恰 相反 ， 该 值 同样 十 分 重要 。 在 InnoDB 存 储 引 擎 中 ， 对 内 存 的 管理 
是 通过 一 种 称 为 内 存 扒 Cheap) 的 方式 进行 的 。 在 对 一 些 数据 结构 本 号 
的 内 存 进行 分 配 时 ， 需 要 从 额外 的 内 存 池 中 进行 申请 ， 当 该 区 域 的 内 存 
不 够 时 ， 会 从 缓冲 池 中 进行 申请 。 例 如 ， 分 配 了 缓冲 池 
(innodb buffer pool) ， 但 是 每 个 绥 冲 池 中 的 帧 缓冲 Cframe buffer) 还 
有 对 应 的 缓冲 控制 对 象 (buffer control block) ， 这 些 对 象 记录 了 一 些 诸 
如 LRU、 锁 、 等 待 等 信息 ， 而 这 个 对 象 的 内 存 需 要 从 额外 内 存 池 中 申 
请 。 因 此 ， 在 申请 了 很 大 的 InnoDB 绥 冲 池 时 ， 也 应 考虑 相应 地 增加 这 


个 值 。 





2.4 Checkpoint 技术 


前 面 已 经 讲 到 了 ， 绥 冲 池 的 设计 目的 为 了 协调 CPU 速 度 与 磁盘 速度 
的 鸿沟 。 因 此 页 的 操作 首先 都 是 在 缓冲 池 中 完成 的 。 如 果 一 条 DML 语 
颁 ， 如 Update 或 Delete 改 变 了 页 中 的 记录 ， 那 么 此 时 页 是 脏 的 ， 即 缓冲 
A a i el 
ERE o 


倘若 每 次 一 个 页 发 生变 化 ， 就 将 新 页 的 版 本 刷新 到 磁盘 ， 那 么 这 个 
开销 是 非常 大 的 。 若 热点 数据 集中 在 某 几 个 页 中 ， 那 么 数据 库 的 性 能 将 
变 得 非常 差 。 同 时 ， 如 果 在 从 缓冲 池 将 页 的 新 版 本 刷新 到 磁盘 时 发 生 了 
宕 机 ， 那 么 数据 就 不 能 恢复 了 。 为 了 避免 发 生 数据 丢失 的 问题 ， 当 前 事 
务 数据 库 系 统 普遍 都 采用 了 Write Ahead Log 策 略 ， 即 当 事 务 提交 时 ， 先 
写 重 做 日 志 ， 再 修改 页 。 当 由 于 发 生 宕 机 而 导致 数据 丢失 时 ， 通 过 重 做 
ee oe DUE 
Ko 














思考 下 面 的 场景 ， 如 果 重 做 日 志 可 以 无 限 地 增 大 ， 同 时 缓冲 池 也 足 
够 大 ， 能 够 缓冲 所 有 数据 库 的 数据 ， 那 么 是 不 需要 将 缓冲 池 中 页 的 新 版 
本 刷新 回 磁盘 。 因 为 当 发 生 宕 机 时 ， 完 全 可 以 通过 重 做 日 志 来 恢复 整个 
数据 库 系统 中 的 数据 到 宕 机 发 生 的 时 刻 。 但 是 这 需要 两 个 前 提 条 件 : 


口 缓冲 池 可 以 缓存 数据 库 中 所 有 的 数据 ; 
口 重 做 日 志 可 以 无 限 增 大 。 


对 于 第 一 个 前 提 条 件 ， 有 经 验 的 用 户 都 知道 ， 当 数据 库 刚 开始 创建 
时 ， 表 中 没有 任何 数据 。 组 冲 池 的 确 可 以 缓存 所 有 的 数据 库 文 件 。 然 而 
随 着 市 场 的 推广 ， 用 户 的 增加 ， 产 品 越 来 越 受 到 关注 ， 使 用 量 也 越 来 越 
大 。 这 时 负责 后 台 存 储 的 数据 库 的 容量 必定 会 不 断 增 大 。 当 前 3TB 的 
MVySQL 数 据 库 已 并 不 少见 ， 但 是 3 TB 的 内 存 却 非常 少见 。 目 前 Oracle 
Exadata 旗 舰 数据 库 一 体 机 也 就 只 有 2 TB 的 内 存 。 因 此 第 一 个 假设 对 于 
生产 环境 应 用 中 的 数据 库 是 很 难得 到 保证 的 。 


再 来 看 第 二 个 前 提 条 件 : 重 做 日 志 可 以 无 限 增 大 。 也 许 是 可 以 的 ， 
但 是 这 对 成 本 的 要 求 太 高 ， 同 时 不 便于 运 维 。DBA 或 SA 不 能 知道 什么 
时 候 重 做 日 志 是 否 已 经 接近 于 磁盘 可 使 用 空间 的 国 值 ， 并 且 要 让 存储 设 









































备 文 持 可 动态 扩展 也 是 需要 一 定 的 技巧 和 设备 文 持 的 。 


好 的 ， 即 使 上 述 两 个 条 件 都 满足 ， 那 么 还 有 一 个 情况 需要 考 碟 : d 
机 后 数据 库 的 恢复 时 间 。 当 数据 库 运 行 了 几 个 月 甚至 几 年 时 ， 这 时 发 生 
人 











因此 Checkpoint〈 检 查 点 ) 技术 的 目的 是 解决 以 下 几 个 问题 : 
口 缩短 数据 库 的 恢复 时 间 ; 

口 缓冲 池 不 够 用 时 ， 将 脏 页 刷新 到 磁盘 ; 

口 重 做 日 志 不 可 用 时 ， 刷 新 脏 页 。 


当 数 据 库 发 生 宕 机 时 ， 数 据 库 不 需要 重 做 所 有 的 日 志 ， 因 为 
Checkpoint 之 前 的 页 都 已 经 刷新 回 磁 往 。 故 数据 库 只 需 对 Checkpoint 后 
的 重 做 日 志 进 行 恢复 。 这 样 惑 大 大 缩短 了 恢复 的 时 间 。 


此 外 ， 当 缓冲 池 不 够 用 时 ， 根 据 LRU 算 法 会 溢出 最 近 最 少 使 用 的 
页 ， 拓 此 页 为 及 页， 那么 需要 强制 执行 Checkpoint， 将 脏 页 也 就 是 页 的 
新 版 本 刷 回 磁盘 。 


重 做 日 志 出 现 不 可 用 的 情况 是 因为 当前 事务 数据 库 系 统 对 重 做 日 志 
的 设计 都 是 循环 使 用 的 ， 并 不 是 让 其 无 限 增 大 的 ， 这 从 成 本 及 管理 上 都 
古 比 较 困 难 的 。 重 做 日 志 可 以 被 重用 的 部 分 是 指 这 些 重 做 日 志 已 经 不 再 
需要 ， 即 当 数 据 库 发 生 宕 机 时 ， 数 据 库 恢复 操作 不 需要 这 部 分 的 重 做 日 
志 ， 因 此 这 部 分 就 可 以 被 覆盖 重用 。 若 此 时 重 做 日 志 还 需要 使 用 ， 那 么 
人 
E. 


对 于 InnoDB 存 储 引 擎 而 言 ， 其 是 通过 LSN (Log Sequence 
Number) 来 标记 版 本 的 。 而 LSN 是 8 字 节 的 数字 ， 其 单位 是 字 节 。 每 个 
页 有 LSN， 重 做 日 志 中 也 有 LSN，Checkpoint 也 有 LSN。 可 以 通过 命令 
SHOW ENGINE INNODB STATUS 来 观察 : 

















mysql- SHOW ENGINE INNODB STATUS\G; 


Log sequence number 92561351052 
Log flushed up to 92561351052 
Last checkpoint at 92561351052 





在 InnoDB 存 储 引 擎 中 ，Checkpoint 发 生 的 时 间 、 条 件 及 脏 页 的 选择 
等 都 非常 复杂 。 而 Checkpoint 所 做 的 事情 无 外 乎 是 将 缓冲 池 中 的 脏 页 刷 
回 到 了 磁盘。 不同 之 处 在 于 每 次 刷新 多 少 页 到 磁盘 ， 每 次 从 哪里 取 脏 页 ， 
以 及 什么 时 间 触 发 Checkpoint。 在 InnoDB 存 储 引 擎 内 部 ， 有 两 种 
Checkpoint， 分 别 为 : 


LI Sharp Checkpoint 
Ll Fuzzy Checkpoint 


Sharp Checkpoint 发 生 在 数据 库 关 闭 时 将 所 有 的 脏 页 都 刷新 回 磁盘 ， 
这 是 默认 的 工作 方式 ， 即 参数 innodb_fast _ shutdown=1。 


但 是 若 数 据 库 在 运行 时 也 使 用 Sharp Checkpoint， 那 么 数据 库 的 可 用 
性 就 会 受到 很 大 的 影响 。 故 在 InnoDB 存 储 引擎 内 部 使 用 Fuzzy 
的 刷新 ， 即 只 刷新 一 部 分 脏 页 ， 而 不 是 刷新 所 有 的 及 
页 回 磁盘 。 


这 里 笔者 进行 了 概括 ， 在 ImnoDB 存 储 引擎 中 可 能 发 生 如 下 几 种 情 
况 的 Fuzzy Checkpoint: 














L1 Master Thread Checkpoint 

LIFLUSH  LRU LIST Checkpoint 

LI Async/Sync Flush Checkpoint 

Ll Dirty Page too much Checkpoint 

对 于 Master Thread 〈2.5 节 会 详细 介绍 各 个 版 本 中 Master Thread f] Sz 
现 ) 中 发 生 的 Checkpoint， 差 不 多 以 每 秒 或 每 十 秒 的 速度 从 缓冲 池 的 脏 
页 列表 中 刷新 一 定 比例 的 页 回 磁 盘 。 这 个 过 程 是 异步 的 ， 即 此 时 
InnoDB 存 储 引 擎 可 以 进行 其 他 的 操作 ， 用 户 查 询 线程 不 会 阻 寿 。 


FLUSH LRU LIST ”Checkpoint 是 因为 InnoDB 存 储 引 擎 需要 保证 

















LRU 列 表 中 需要 有 差不多 100 个 空闲 页 可 供 使 用 。 在 InnoDB1.1.x 版 本 之 
前 ， 需 要 检查 LRU 列 表 中 是 否 有 足够 的 可 用 空间 操作 发 生 在 用 户 查 询 线 
程 中 ， 显 然 这 会 阻塞 用 户 的 查询 操作 。 倘 知 没 有 100 个 可 用 空 亲 页 ， 那 
么 InnoDB 存 储 引 擎 会 将 LRU 列 表 尾 端的 页 移 除 。 如 果 这 些 页 中 有 及 

页 ， 那 么 需要 进行 Checkpoint， 而 这 些 页 是 来 自 LRU 列 表 的 ， 因 此 称 为 
FLUSH LRU LIST Checkpoint. 


而 从 MySQL 5.6 版 本 ， 也 就 是 InnoDB1.2.x 版 本 开始 ， 这 个 检查 被 放 
在 了 一 个 单独 的 Page Cleaner 线 程 中 进行 ， 并 且 用 户 可 以 通过 参数 
innodb_lru_scan_depth 控 制 LRU 列 表 中 可 用 页 的 数量 ， 该 值 默认 为 
1024, 1: 





ORO E KO ROO ROG IO ROO RO ROG] po ek ok e ek eR e e e eek 





Async/Sync Flush Checkpoint 指 的 是 重 做 日 志文 件 不 可 用 的 情况 ， 这 
时 需要 强制 将 一 些 页 刷新 回 磁盘 ， 而 此 时 脏 页 是 从 脏 页 列表 中 选取 的 。 
知 将 已 经 写 入 到 重 做 日 志 的 LSN 记 为 redo_lsn， 将 已 经 刷新 回 磁盘 最 新 
页 的 LSN 记 为 checkpoint_ lsn， 则 可 定义 : 











checkpoint age-redo lsn-checkpoint lsn 





再 定义 以 下 的 变量 : 





async_water_mark=75%*total_redo_log_file_size 
sync. og_file_si 


yl water mark-90X*total redo 1l g file size 





若 每 个 重 做 日 志文 件 的 大 小 为 1GB， 并 且 定 义 了 两 个 重 做 日 志文 
件 ， 则 重 做 日 志文 件 的 总 大 小 为 2GB。 那 么 async_water_mark=1.5GB， 
sync water mark-1.8GB. Ml): 


口 当 checkpoint_age<async_water_mark 时 ， 不 需要 刷新 任何 脏 页 到 
Hea s 


La?5async water mark- checkpoint age- sync water marklh] fit /z 
Async ”Flush， 从 Flush 列 表 中 刷新 足够 的 脏 页 回 磁盘 ， 使 得 刷新 后 满足 


checkpoint age-async water mark; 


口 checkpoint_ age 之 sync_water_mark 这 种 情况 一 般 很 少 发 生 ， 除 非 
设置 的 重 做 日 志文 件 太 小 ， 并 且 在 进行 类 似 LOAD DATA 的 BULK 
INSERT 操 作 。 此 时 触发 Sync Flush 操 作 ， 从 Flush 列 表 中 刷新 足够 的 脏 页 
回 磁盘 ， 使 得 刷新 后 满足 checkpoint_age<async_water_mark。 


可 见 ，Async/Sync Flush Checkpoint 是 为 了 保证 重 做 日 志 的 循环 使 用 
的 可 用 性 。 在 InnoDB 1.2.x 版 本 之 前 ，Async Flush Checkpoint 会 阻塞 发 
现 问 题 的 用 户 查 询 线 程 ， 而 Sync Flush Checkpoint 会 阻塞 所 有 的 用 户 查 
询 线 程 ， 并 且 等 待 脏 页 刷新 完成 。 从 ImnoDB 1.2.x 版 本 开始 LAE 
MySQL 5.6 版 本 ， 这 部 分 的 刷新 操作 同样 放 入 到 了 单独 的 Page Cleaner 
Thread 中 ， 故 不 会 阻塞 用 户 碍 询 线程 。 


MySQL 官 方 版 本 并 不 能 查看 刷新 页 是 从 Flush 列 表 中 还 是 从 LRU 列 
表 中 进行 Checkpoint 的 ， 也 不 知道 因为 重 做 日 志 ee 
Flush 的 次 数 。 但 是 InnoSQL 版 本 提供 了 方法 ， 可 以 通过 命令 SHOW 
ENGINE INNODB STATUS 来 观察 ， 如 : 

















mysql- SHOW ENGINE INNODB STATUS\G; 


ORO ICICI ICI ICICI GIGI py Re ek e eR eR e e e ee 


LRU SERIOUS ,unzi ip | rig Ts n:0 
I/O sum[0]:cur[6], unz um[0] :cur [0] 
Async Flush:0, Sync Flu ih. O,LRU List Flush:0,Flush List Flush:111736 


1 row in set(0.01 sec) 





根据 上 述 的 信息 ， 还 可 以 对 InnoDB 存 储 引 擎 做 更 为 深入 的 调 优 ， 
部 分 将 在 第 9 章 中 讲述 


最 后 一 种 Checkpoint 的 情况 是 Dirty Page too ub. 即 脏 页 的 数量 太 
多 ， 导 致 mnoDB 存 储 引 擎 强制 进行 Checkpoint。 其 目的 总 的 来 说 还 是 为 
了 保证 缓冲 池 中 有 足够 可 用 的 页 。 其 可 由 参数 
innodb max dirty pages pctizil: 
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innodb_max_dirty_pages_pct 值 为 75 表 示 ， 当 缓冲 池 中 脏 页 的 数量 占 


据 75% 时 ， 强 制 进行 Checkpoint， 刷 新 一 部 分 的 脏 页 到 人 磁盘。 在 InnoDB 
1.0.x 版 本 之 前 ， 该 参数 默认 值 为 900， 之 后 的 版 本 都 为 75。 


2.5 Master Thread 工作 方式 


在 2.3 节 中 我 们 知道 了 ，InnoDB 存 储 引 擎 的 主要 工作 都 是 在 一 个 单 
独 的 后 从 线程 Master Thread 中 完成 的 ， 这 一 节 将 具体 解释 该 线程 的 具体 
实现 及 该 线程 可 能 存在 的 问题 。 


2.5.1 InnoDB 1.0.x 厂 本 之 前 的 Master Thread 


Master Thread 具 有 最 高 的 线程 优先 级 别 。 其 内 部 由 多 个 循环 
(loop) 组 成 : 主 循环 Coop) 、 后 台 循 环 Cbackgroup loop) 、 刷 新 循 
环 (flush loop) 、 和 暂停 循环 (suspend loop) . Master Thread 会 根据 数据 
库 运 行 的 状态 在 loop、background loop. flush loop 和 suspendloop 中 进行 
切换 。 


Loop 被 称 为 主 循环 ， 因 为 大 多 数 的 操作 是 在 这 个 循环 中 ， 其 中 有 两 
大 部 分 的 操作 一 一 每 秒 钟 的 操作 和 每 10 秒 的 操作 。 伪 代码 如 下 : 








int i=0;i<10;i++){ 








可 以 看 到 ，loop 循 环 通过 thread sleep 来 实现 ， 这 意味 着 所 谓 的 每 秒 
一 次 或 每 10 秒 一 次 的 操作 是 不 精确 的 。 在 负载 很 大 的 情况 下 可 能 会 有 延 
ÀR (delay) ， 只 能 说 大 概 在 这 个 频率 下 。 当 然 ，InnoDB 源 代码 中 还 通 
过 了 其 他 的 方法 来 尽量 保证 这 个 频率 。 

每 秒 一 次 的 操作 包括 : 

口 日 志 绥 冲刷 新 到 人 磁盘， 即使 这 个 事务 还 没有 提交 【〈 总 是 ) ; 

OHA Bt CARE 

Q2 £m 8 100 InnoDB Z virt FAY i va BCH BE 

口 如 果 当 前 没有 用 户 活动 ， 则 切换 到 background loop (E) . 








即使 某 个 事务 还 没有 提交 ，InnoDB 存 储 引 擎 仍然 每 秒 会 将 重 做 日 
志 绥 冲 中 的 内 容 刷 新 到 重 做 日 志文 件 。 这 一 点 是 必须 要 知道 的 ， 因 为 这 
可 以 很 好 地 解释 为 什么 再 大 的 事务 提交 (commit〉 的 时间 也 是 很 短 的 。 


合并 插入 缓冲 〈Insert Buffer) 并 不 是 每 秒 都 会 发 生 的 。InnoDB 存 
储 引 擎 会 判断 当前 一 秒 内 发 生 的 IO 次 数 是 否 小 于 5 次 ， 如 果 小 于 5 次 ， 
InnoDB 认 为 当前 的 IO 压力 很 小 ， 可 以 执行 合并 插入 缓冲 的 操作 。 


同样 ， 刷 新 100 个 脏 页 也 不 是 每 秒 都 会 发 生 的 。InnoDB 存 储 引 擎 通 
过 判断 当前 缓冲 池 中 脏 页 的 比例 Cbuf_get_modified_ratio_pct) 是 否 超 
过 了 配置 文件 中 innodb_max_dirty_pages_pct 这 个 参数 (默认 为 9009， 代 表 
9096) ， 如 果 超 过 了 这 个 闪 值 ，InnoDB 存 储 引 擎 认为 需要 做 磁盘 同步 的 
操作 ， 将 100 个 脏 页 写 入 磁盘 中 。 


总 结 上 述 操作 ， 伪 代码 可 以 进一步 具体 化 ， 如 下 所 示 : 








master_thread(){ 
loop; 


disk 


int 1=0;1<10;i++){ 
ad_sleep(1)//sleep 1 secon d 
og buffer flush to 

t ios<5 


H: 
ho 


oh 
ta ALA 


nsert buffer 
ied_ratio_pct>innodb_max_dirty_pages_pct) 
lush 100 dirty page 
ity) 


WEeRBTOAVOrROAKMAKAthAHA < 
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接着 来 看 每 10 秒 的 操作 ， 包 括 如 下 内 容 : 

口 刷 新 100 个 脏 页 到 磁盘 〈 可 能 的 情况 下 ) ; 

口 合并 至 多 5 个 插入 缓冲 《总 是 ) ; 

口 将 日 志 缓冲 刷新 到 磁盘 〈 总 是 ) ; 

口 删除 无 用 的 Undo 页 〈 总 是 ) ; 

口 刷新 100 个 或 者 10 个 脏 页 到 磁盘 〈 总 是 ) 。 

在 以 上 的 过 程 中 ，InnoDB 存 储 引擎 会 先 判断 过 去 10 秒 之 内 磁盘 的 


IO 操作 是 否 小 于 200 次 ， 如 果 是 ，ImnoDB 存 储 引 人 擎 认为 当前 有 足够 的 磁 
盘 IO 操 作 能 力 ， 因 此 将 100 个 脏 页 刷新 到 磁盘 。 接 痢 ，InnoDB 存 储 引 擎 
会 合并 插入 缓冲 。 不 同 于 每 秒 一 次 操作 时 可 能 及 生 的 合并 插入 缓冲 操 
作 ， 这 次 的 合并 插入 缓冲 操作 总 会 在 这 个 阶段 进行 。 之 后 ，InnoDB 存 
储 引 擎 会 再 进行 一 次 将 日 志 组 冲刷 新 到 磁盘 的 操作 。 这 和 每 秒 一 次 时 发 
生 的 操作 是 一 样 的 。 


接着 InnoDB 存 储 引 苟 会 进行 一 步 执 行 full purge 操 作 ， 即 删除 无 用 的 
Undo 页 。 对 表 进 行 update、delete 这 类 操作 时 ， 原 先 的 行 被 标记 为 删 
除 ， 但 是 因为 一 致 性 读 〈consistent read) 的 关系 ， 需 要 保留 这 些 行 版 本 
的 信息 。 但 是 在 full purge 过 程 中 ，InnoDB 存 储 引 擎 会 判断 当前 事务 系统 
中 己 被 删除 的 行 是 否 可 以 删除 ， 比 如 有 时 候 可 能 还 有 查询 操作 需要 读 取 
之 前 版 本 的 undo 人 信息， 如 果 可 以 删除 ，InnoDB 会 立即 将 其 删除 。 从 源 
代码 中 可 以 发 现 ，InnoDB 存 储 引 苟 在 执行 full purge 操 作 时 ， 每 次 最 多 尝 
试 回收 20 个 undo 页 。 


然后 ，InnoDB 存 储 引 擎 会 判断 绥 剖 池 中 脏 页 的 比例 
(buf get modified ratio pcO ， 如 果 有 超过 70% 的 脏 页 ， 则 刷新 100 个 
脏 页 到 磁盘 ， 如 果 脏 页 的 比例 小 于 70%， 则 只 需 刷 新 10% 的 脏 页 到 磁 
BH. 


mL 











à 现在 我 们 可 以 完整 地 把 主 循环 Cain loop) 的 伪 代 码 写 出 来 了 ， 内 
FU F: 





void master_thread(){ 
00p; 


loop: 

for(int i=0;i<10;i++){ 

thread_sleep(1)//sleep 1 secon d 
g buffer flush to di 

(last_one_second_ios<5) 


0 
e 
e at most 5 ff 
uf get modified ratio pct-innodb max dirty pages pct) 
age 


st ten second ios-200) 

fer pool flush 100 dirty page 

erge at most insert buffer 

og buffer flush to disk 

l purge 
et modified ratio pct- 7096) 

uffer pool flush 100 dirty page 





ah 


""Qococococrmeocococcomnm-euonranu 
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接着 来 看 background loop， 知 当前 没有 用 户 活动 〈 数 据 库 空 亲 时 ) 


或 者 数据 库 关 闭 (shutdown) ， 束 会 切换 到 这 个 循环 。background loop 
会 执行 以 下 操作 : 


口 删 除 无 用 的 Undo 页 (总 是 ) ; 
口 合并 20 个 插入 缓冲 (总 是 ) ; 
口 跳 回 到 主 循环 〈 总 是 ) ; 


口 不 断 刷 新 100 个 页 直到 符合 条 件 ( 可 能 ， 跳 转 到 flush loopt ë 
成 ) 。 


“flush loop 中 也 没有 什么 事情 可 以 做 了 ，InnoDB 存 储 引 擎 会 切换 
到 suspend loop， 将 Master Thread 持 起， 等 待 事件 的 发 生 。 奉 用 户 启 用 
Cenable) 了 InnoDB 存 储 引 擎 ， 却 没有 使 用 任何 InnoDB 存 储 引 擎 的 表 ， 
那么 Master Thread 总 是 处 于 挂 起 的 状态 。 


最 后 ，Master Thread 完 整 的 伪 代 码 如 下 : 





void master_thread(){ 
op; 


for(int i=0;i<10;i++ 
thread_sleep(1)//sleep 1 second 

do log buffer flush to disk 

if (last_one_second_ios<5) 

do merge at most 5 insert buffer 

if (buf_get_modified_ratio_pct >innodb_max_dirty_pages_pct) 
do buffer pool flush 100 dirty page 

if(no user activity) 
goto backgroud loop 


if (last_ten_second_ios<200) 
do buffer pool flush 100 dirty page 
do merge at most 5 insert buffer 
do log buffer flush to disk 
do full purge 

if (buf_get_modified_ratio_pct >70%) 
do buffer pool flush 100 dirty page 








se 
buffer pool flush 10 dirty page 
goto loop 

background loop: 

do full purge 

do merge 20 insert buffer 

if not idle: 

goto loop: 


goto flush loop 

flush loop: 

do buffer pool flush 100 dirty page 
if(buf get modified ratio pct-innodb max dirty pages pct) 
goto flush loop 

goto suspend loop 

suspend loop: 

suspend thread() 

waiting event 

goto loop; 

} 


es | 


2.5.2 ”InnoDB1.2.x 版 本 之 前 的 Master Thread 


在 了 解 了 1.0.x 版 本 之 前 的 Master Thread 的 具体 实现 过 程 后 ， 细 心 的 
读者 会 发 现 InnoDB 存 储 引 擎 对 于 IO 其 实 是 有 限制 的 ， 在 缓冲 池 问 磁盘 
刷新 时 其 实 都 做 了 一 定 的 硬 编码 Chard coding) 。 在 磁盘 技术 飞速 发 展 
的 今天 ， 当 固态 磁盘 〈SSD) 出 现时 ， 这 种 规定 在 很 大 程度 上 限制 了 
InoDB 存 储 引擎 对 磁盘 IO 的 性 能 ， 尤 其 是 写 入 性 能 。 


从 前 面 的 盆 代 码 来 看 ， 无 论 何 时 ，InnoDB 存 储 引 擎 最 大 只 会 刷新 
100 个 脏 页 到 磁盘 ， 合 并 20 个 插入 绥 冲 。 如 果 是 在 写 入 密集 的 应 用 程序 
中 ， 每 秒 可 能 会 产生 大 于 100 个 的 脏 页 ， 如 果 是 产生 大 于 20 个 插入 缓冲 
的 情况 ，Master Thread 似 乎 会 “ 忙 不 过 来 "， 或 者 说 它 总 是 做 得 很 慢 。 即 
使 磁盘 能 在 1 秒 内 处 理 多 于 100 个 页 的 写 入 和 20 个 插入 缓冲 的 合并 ， 但 是 
由 于 hard coding, Master Thread 也 只 会 选择 刷新 100 个 脏 页 和 合并 20 个 插 
入 绥 冲 。 同 时 ， 当 发 生 宕 机 需要 恢复 时 ， 由 于 很 多 数据 还 没有 刷新 回 磁 
盘 ， 会 导致 恢复 的 时 间 可 能 需要 很 信 ， 尤 其 是 对 于 insert buffer 来 说 。 


这 个 问题 最 初 由 Google 的 工程 师 Mark Callaghan 提 出 ， 之 后 InnoDB 
官方 对 其 进行 了 修正 并 发 布 了 补丁 patch) 。InnoDB 存 储 引 警 的 开发 
队 参 考 了 Google 的 patch， 提 供 了 类 似 的 方法 来 修正 该 问题 。 因 此 
InnoDB Plugin 〈 从 InnoDB1.0.x 版 本 开始 ) 提供 了 参数 
innodb_io_capacity， 用 来 表示 磁盘 IO 的 吞吐 量 ， 默 认 值 为 200。 对 于 刷 
新 " 磁盘 页 的 数量 ， 会 按照 innodb_io_capacity 的 百分比 来 进行 控制 。 规 
则 如 下 : 


口 在 合并 插入 缓冲 时 ， 合 并 插入 缓冲 的 数量 为 innodb_io_capacity 值 
的 5%; 


口 在 从 缓冲 区 刷新 脏 页 时 ， 刷 新 脏 页 的 数量 为 innodb_io_capacity。 

右 用 户 使 用 了 SSD 类 的 磁盘 ， 或 者 将 几 块 磁盘 做 了 RAID， 当 存储 
设备 拥有 更 高 的 IO 速度 时 ， 完 全 可 以 将 innodb_io_capacity 的 值 调 得 再 高 
点 ， 直 到 符合 磁盘 IO 的 吞吐 量 为 止 。 

另 一 个 问题 是 ， 参 数 innodb_max_dirty_pages_pct 默 认 值 的 问题 ， 在 


InnoDB 1.0.x 版 本 之 前 ， 该 值 的 默认 为 90， 意 味 着 脏 页 占 组 冲 池 的 
90%。 但 是 该 值 “ 太 大 >” 了， 因为 InhnnoDB 存 储 引 擎 在 每 秒 刷新 缓冲 池 和 




















flush loop 时 会 判断 这 个 值 ， 如 果 该 值 大 于 innodb_max_dirty_pages_pct， 
才 刷 新 100 个 脏 页 ， 如 果 有 很 大 的 内 存 ， 或 者 数据 库 服务 器 的 压力 很 
大 ， 这 时 刷新 脏 页 的 速度 反而 会 降低 。 同 样 ， 在 数据 库 的 恢复 阶段 可 能 
需要 更 多 的 时 间 。 


在 很 多 论坛 上 都 有 对 这 个 问题 的 讨论 ， 有 人 甚至 将 这 个 值 调 到 了 20 
或 10， 然 后 测试 发 现 性 能 会 有 所 提高 ， 但 是 将 
innodb_max_dirty_pages_pct 调 到 20 或 10 会 增加 磁盘 的 压力 ， 系 统 的 负担 
还 是 会 有 所 增加 的 。Google 在 这 个 问题 上 进行 了 测试 ， 证 明 20 并 不 是 一 
个 最 优 值 2。 而 从 ImnoDB 1.0.x 版 本 开始 ，innodb_max_dirty_pages_pct 默 
认 值 变 为 了 75， 和 Google 测 试 的 80 比 较 接 近 。 这 样 既 可 以 加 快 刷新 脏 页 
的 频率 ， 又 能 保证 了 磁盘 IO 的 负载 。 


InnoDB 1.0.x/j Zi 2KHJ — 1 Z2 BE innodb_adaptive_ flushing (E 
适应 地 刷新 》， 该 值 影响 每 秒 刷新 脏 页 的 数量 。 原 来 的 刷新 规则 是 : 及 
页 在 缓冲 池 所 占 的 比例 小 于 innodb_max_dirty_pages_pct 时 ， 不 刷新 脏 
Ji; X Finnodb max dirty pages pctHj, Jp|3r1004- Evi. BH 
innodb_adaptive_flushing 参 数 的 引入 ，InnoDB 存 储 引 擎 会 通过 一 个 名 为 
buf_flush_get_desired_flush_rate 的 函数 来 判断 需要 刷新 脏 页 最 合适 的 数 
量 。 粗 略 地 翻阅 源 代码 后 发 现 buf_flush_get_desired_flush_rate 通 过 判断 
产生 重 做 日 志 (redo log) 的 速度 来 决定 最 合适 的 刷新 脏 页 数量 。 
此 ， 当 及 页 的 比例 小 于 innodb_max dirty pages_pct 时 ， 也 会 刷新 一 定量 
的 脏 页 。 


还 有 一 个 改变 是 : 之 前 每 次 进行 fall ”purge 操 作 时 ， 最 多 回收 20 个 
Undo 页 ， 从 InnoDB 1.0.x 版 本 开始 引入 了 参数 innodb_purge_batch_size， 
该 参数 可 以 控制 每 次 full purge 回 收 的 Undo 页 的 数量 。 该 参数 的 默认 值 为 
20， 并 可 以 动态 地 对 其 进行 修改 ， 有 具体 如 下 : 
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Value:20 
mysql>SET GLOBAL innodb purge batch size A 
Query OK,0 rows affected(0.00 sec 





通过 上 述 的 讨论 和 人 解释 我 们 知道 ， 从 InnoDB 1.0.x 版 本 开始 ， 
Master Thread 的 伪 代 码 必 将 有 所 改变 ， 最 终 变 成 : 








void master_thread(){ 
goto loop; 
loop: 


for(int i=0;i<10;i++){ 
thread_sleep(1)//sleep 1 second 

do log buffer flush to disk 

if (last_one_second_ios<5%innodb_io_capacity) 

do merge 5%innodb_io_capacity insert buffer 

if (buf_get_modified_ratio_pct >innodb_max_dirty_pages_pct) 
do buffer pool flush 100%innodb_io_capacity dirty page 
else if enable adaptive flush 
do buffer pool flush desired amount dirty page 
if(no user activity) 
goto backgroud loop 


if (last_ten_second_ios<innodb_io_capacity) 

do buffer pool flush 100%innodb_io_capacity dirty page 
do merge 5%innodb_io_capacity insert buffer 

do log buffer flush to disk 
do full purge 

if(buf get modified ratio pct- 7096) 

do buffer pool flush 100%innodb_io_capacity dirty page 
else 
dobuffer pool flush 109&innodb io capacity dirty page 

goto loop 

background loop: 

do full purge 

do merge 1009&innodb io capacity insert buffer 

if not idle: 

goto loop: 

else: 

goto flush loop 

flush loop: 

do buffer pool flush 1009*innodb io capacity dirty page 
if(buf get modified ratio pct-innodb max dirty pages pct) 
go to flush loop 

goto suspend loop 

suspend loop: 

suspend thread() 

waiting event 

goto loop; 

} 











很 多 测试 都 显示 ，InnoDB 1.0.x 版 本 在 性 能 方面 取得 了 极 大 的 提 
高 ， 其 实 这 和 前 面 提 到 的 Master Thread 的 改动 是 密 不 可 分 的 ， 因 为 
InnoDB 存 储 引 擎 的 核心 操作 大 部 分 都 集中 在 Master Thread 后 台 线 程 中 。 


MInnoDB 1.0.x 开 始 ， 命 令 SHOW ENGINE INNODB STATUS 可 以 
查看 当前 Master Thread 的 状态 信息 ， 如 下 所 示 : 











Type:InnoDB 
Name: 
Status: 


srv master thread loops:45 1 second,45 sleeps,4 10 second,6 background,6 flush 
srv master thread log flush and writes:45 log writes only:69 





这 里 可 以 看 到 主 循环 进行 了 45 次 ， 每 秒 挂 起 〈sleep) 的 操作 进行 了 
45 次 《说 明 负 载 不 是 很 大 ) ，10 秒 一 次 的 活动 进行 了 4 次 ， 符 合 1 : 10。 
background loop 进 行 了 6 次 ，flush loop 也 进行 了 6 次 。 因 为 当前 这 台 服 务 
器 的 压力 很 小 ， 所 以 能 在 理论 值 上 运行 。 如 果 是 在 一 台 压 力 很 大 的 
MySQL 数 据 库 服 务 器 上 ， 看 到 的 可 能 会 是 下 面 的 情景 : 





mysql>show engine innodb status\G; 

XOKOOOKOOIO ORO ROIG] ppt 
Type:InnoDB 

Name : 

Status: 


srv master thread 100ps:2188 1 second,1537 sleeps,218 10 second,2 background,2 flush 
srv master thread log flush and writes:1777 log writes only:5816 





可 以 看 到 当前 主 循环 运行 了 2188 次 ， 但 是 循环 中 的 每 秒 挂 起 
(sleep) 的 操作 只 运行 了 1537 次 。 这 是 因为 InnoDB 对 其 内 部 进行 了 一 
些 优化 ， 当 压力 大 时 并 不 总 是 等 待 1 秒 。 因 此 ， 并 不 能 认为 1_second 和 
sleeps 的 值 总 是 相等 的 。 在 某 些 情况 下 ， 可 以 通过 两 者 之 间 差 值 的 比较 
来 反映 当前 数据 库 的 负载 压力 。 


[有 兴趣 的 读者 可 参考 ; http://code.google.com/p/google-mysq]- 
tools/wiki/InnodbloOltpDisk. 





2.5.3 InnoDB 1.2.xh Æ Bj Master Thread 


fEInnoDB 1.2.x 版 本 中 再 次 对 Master Thread 进 行 了 优化 ， 由 此 也 可 
以 看 出 Master Thread 对 性 能 所 起 到 的 关键 作用 。 在 InnoDB 1.2.x 版 本 
rH, Master Thread 的 伪 代 人 码 如 下 : 


if InnoDB is idle 
Sada ste i ido | idle tasks(); 
pom 

ster do active tasks(); 





其 中 srv_master_do_idle_tasks0 就 是 之 前 版 本 中 每 10 秒 的 操作 ， 
srv master do_active_tasks0O 处 理 的 是 之 前 每 秒 中 的 操作 。 同 时 对 于 刷新 
脏 页 的 操作 ， 从 Master ”Thread 线 程 分 离 到 一 个 单独 的 Ra Cleaner 
Thread， 从 而 减轻 了 Master Thread 的 工作 ， 同 时 进一步 提高 了 系统 的 并 
发 性 。 





2.6 ”InnoDB 关 键 特性 
InnoDB 和 存储 引擎 的 关键 特性 包括 : 
口 插入 缓冲 (Insert Buffer) 
口 两 次 写 (Double Write) 
口 目 适应 哈 希 索引 (Adaptive Hash Index) 
口 异步 IO (Async IO) 
口 刷 新 邻接 页 (Flush Neighbor Page) 


| 上 述 这 些 特性 为 InnoDB 存 储 引 擎 带 来 更 好 的 性 能 以 及 更 高 的 可 人 靠 
E 


2.6.1 JAZ 


1.Insert Buffer 


Insert Buffer 可 能 是 InnoDB 存 储 引 擎 关键 特性 中 最 令 人 激动 与 兴 
的 一 个 功能 。 不 过 这 个 名 字 可 能 会 让 人 认为 插入 缓冲 是 缓冲 池 中 的 一 个 
组 成 部 分 。 其 实 不 然 ，InnoDB 绥 冲 池 中 有 Insert Buffer 信息 固然 不 错 ， 
但 是 Insert Buffer 和 数据 页 一 样 ， 也 是 物理 页 的 一 个 组 成 部 分 。 


在 InnoDB 存 储 引擎 中 ， 主 键 是 行 唯一 的 标识 符 。 通 常 应 用 程序 中 
行 记录 的 插入 顺序 是 按照 主键 递增 的 顺序 进行 插入 的 。 因 此 ， 插 入 聚集 
索引 (Primary Key) 一 般 是 顺序 的 ， 不 需要 磁盘 的 随机 读 取 。 比 如 按 下 
列 SQL 定义 表 : 











CREATE TABLE t( 
a INT AUTO INCREMENT, 
b VARCHAR(30), 
PRIMARY KEY(a) 

); 





其 中 a 列 是 自 增长 的 ， 若 对 a 列 插入 NULL 值 ， 则 由 于 其 具有 
AUTO_INCREMENT 属 性 ， 其 值 会 自动 增长 。 同 时 页 中 的 行 记 录 按 a 的 





值 进行 顺序 存放 。 在 一 般 情 况 下 ， 不 需要 随机 读 取 另 一 个 页 中 的 记录 。 
因此 ， 对 于 这 类 情况 下 的 插入 操作 ， 速 度 是 非常 快 的 。 


注意 ”并 不 是 所 有 的 主键 插入 都 是 顺序 的 。 知 主键 类 是 UUID 这 样 
的 类 ， 那 么 插入 和 辅助 索引 一 样 ， 同 样 是 随机 的 。 即 使 主键 是 自 增 类 
型 ， 但 是 插入 的 是 指定 的 值 ， 而 不 是 NULL 值 ， 那 么 同样 可 能 导致 插入 
并 非 连续 的 情况 。 


但 是 不 可 能 每 张 表 上 只 有 一 个 聚集 索引 ， 更 多 情况 下 ， 一 张 表 上 有 
多 个 非 聚 集 的 辅助 索引 Csecondary index) 。 比 如 ， 用 户 需 要 按照 b 这 个 
oo 并 且 b 这 个 字段 不 是 唯一 的 ， 即 表 是 按 如 下 的 SQL 语句 
定义 的 : 




















CREATE TABLE t( 

INT AUTO_INCREMENT, 
b VARCHAR(30), 
PRIMARY KEY(a), 

ey(b) 


在 这 样 的 情况 下 产生 了 一 个 非 聚 集 的 且 不 是 唯一 的 索引 。 在 进行 插 

入 操作 时 ， 数 据 页 的 存放 还 是 按 主键 a 进 行 顺序 存放 的 ， 但 是 对 于 非 聚 

集 索引 叶子 节点 的 插入 不 再 是 顺序 的 了 ， 这 时 就 需要 离散 地 访问 非 聚集 

索引 页 ， 由 于 随机 读 取 的 存在 而 导致 了 插入 操作 性 能 下 降 。 当 然 这 并 不 

是 这 个 b 字 段 上 索引 的 错误 ， 而 是 因为 B+ 树 的 特性 决定 了 砷 林 集 索引 
9 离散 性 。 


再 要 注意 的 是 ， 在 某 些 情况 下 ， 辅 助 索 引 的 插入 依然 是 顺序 的 ， 或 
者 说 是 比较 顺序 的 ， 比 如 用 户 购 买 表 中 的 时 间 字 段 。 在 通 肖 情况 下 ， 用 
户 购买 时 间 是 一 个 辅助 索引 ， 用 来 根据 时 间 条 件 进行 查询 。 但 是 在 插入 
时 却 是 根据 时 间 的 递增 而 插入 的 ， 因 此 插入 也 是 “较为 ?顺序 的 。 


InnoDB 存 储 引 擎 开创 性 地 设计 了 Isert Buffer， 对 于 非 聚 集 索 引 的 
插入 或 更 新 操作 ， 不 是 每 一 次 直接 插入 到 索引 页 中 ， 而 是 先 判断 插入 的 
ARR S| TE ES, FE. URSA; ADE, MERA 
到 一 个 Insert Buffer 对 象 中 ， 好 似 欺骗 。 数 据 库 这 个 非 聚 集 的 索引 已 经 插 
到 叶子 节点 ， 而 实际 并 没有 ， 只 是 存放 在 另 一 个 位 置 。 然 后 再 以 一 定 的 
频率 和 情况 进行 Insert Buffer 和 辅助 索引 页 子 节 点 的 merge (ASF) $E 
作 ， 这 时 通常 能 将 多 个 插入 合并 到 一 个 操作 中 (因为 在 一 个 索引 页 
F) ， 这 就 大 大 提高 了 对 于 非 肾 集 索 引 插 入 的 性 能 。 




















然而 Insert Buffer 的 使 用 需要 同时 满足 以 下 两 个 条 件 : 
口 索引 是 辅助 索引 (secondary index) ; 
口 索引 不 是 唯一 unique) ff. 


当 满 足以 上 两 个 条 件 时 ，InnoDB 存 储 引 擎 会 使 用 Insert Buffer, ix 
样 惑 能 提高 插入 操作 的 性 能 了 。 不 过 考虑 这 样 一 种 情况 : 应 用 程序 进行 
大 量 的 插入 操作 ， 这 些 都 涉及 了 不 唯一 的 非 聚集 索引 ， 也 就 是 使 用 了 
Inset — Buffer。 知 此 时 MySQL 数 据 库 发 生 了 宕 机 ， 这 时 势必 有 大 量 的 
Insert Buffer 并 没有 合并 到 实际 的 非 聚集 索引 中 去 。 因 此 这 时 恢复 可 能 需 
要 很 长 的 时 间 ， 在 极端 情况 下 其 至 需要 几 个 小 时 。 


辅助 索引 不 能 是 唯一 的 ， 因 为 在 插入 缓冲 时 ， 数 据 库 并 不 去 查找 索 
引 页 来 判断 插入 的 记录 的 唯一 性 。 如 果 去 查找 肯定 又 会 有 离散 读 取 的 情 
况 发 生 ， 从 而 导致 Insert Buffer 失 去 了 意义 。 


用 户 可 以 通过 命令 SHOW ENGINE INNODB STATUS 来 查看 插入 组 
冲 的 信息 : 











mysql- SHOW ENGINE INNODB aay 


JÓRGOOR OR IOI IO IOI GI ICI IO IOIGR pK Re IOI GR ICR IO IO IOI RO I Ie 


Per second averages calculated from the last 44 seconds 


Ibuf:size 7545,free list len Shans eg size 11336, 
8075308 inserts,7540969 merged ,2246304 merges 


1 row in set(0.00 sec) 





seg ， size 显示 了 当前 Insert ”Buffer 的 大 小 为 11336x16KB， 大 约 为 
177MB; free list len 代 表 了 空 内 列表 的 长 度 ; size 代 表 了 已 经 合并 记录 页 
的 数量 。 而 黑体 部 分 的 第 2 行 可 能 是 用 户 真 正 天 心 的 ， 因 为 它 显示 了 插 

入 性 能 的 提高 。Inserts 代 表 了 插入 的 记录 数 ;， merged ” recs 代表 了 合并 的 
插入 记录 数量 ， merges 代 表 合 并 的 次 数 ， 也 就 是 实际 读 取 页 的 次 数 ， 
merges: merged recs K 9731 : 3， 代 表 了 插入 绥 冲 将 对 于 非 聚集 索引 页 的 

离散 IO 逻 辑 请 求 大 约 降低 了 2/3。 





正如 前 面 所 说 的 ， 目 前 Insert Buffer 存 在 一 个 问题 是 : 在 写 密 集 的 情 
况 下 ， 揪 入 缓冲 会 占用 过 多 的 缓冲 池内 存 (innodb_buffer_ pooD ， 默 认 
最 大 可 以 占用 到 1/2 的 缓冲 池内 存 。 以 下 是 InnoDB 存 储 引 擎 源 代码 中 对 
insert buffer 的 初始 化 操作 : 





/**Buffer pool size per the maximum insert buffer size*/ 
#define IBUF POOL SIZE PER MAX SIZE 2 

ibuf--—max size-buf pool get curr size()/UNIV PAGE SIZE 
/IBUF POOL SIZE PER MAX SIZE; 








这 对 于 其 他 的 操作 可 能 会 带 来 一 定 的 影响 。Percona 上 发 布 一 些 
patch 来 修正 插入 组 冲 占 用 太 多 绥 冲 池内 存 的 情况 ， 有 基体 可 以 到 Percona 
官网 进行 查找 。 简 单 来 说 ， 修 改 IBUF_POOL_SIZE_PER_MAX_SIZE 就 
可 以 对 插入 缓冲 的 大 小 进行 控制 。 比 如 将 
IBUF POOL_SIZE_PER_MAX_SIZE 改 为 3， 则 最 大 只 能 使 用 1/3 的 缓冲 
池内 存 。 


2.Change Buffer 


InnoDB 从 1.0.x 版 本 开始 引入 了 Change Buffer， 可 将 其 视 为 Insert 
Buffer 的 升级 。 从 这 个 版 本 开始 ，InnoDB 存 储 引擎 可 以 对 DML 操 作 
INSERT、DELETE、UPDATE 都 进行 缓冲 ， 他 们 分 别 是 : Insert 
Buffer、 Delete Buffer、Purge buffer。 


当然 和 之 前 Insert Buffer 一 样 ，Change Buffer 适 用 的 对 象 依然 是 非 唯 
一 的 辅助 索引 。 


对 一 条 记录 进行 UPDATE 操 作 可 能 分 为 两 个 过 程 : 
口 将 记录 标记 为 已 删除 ; 
口 真 正 将 记录 删除 。 


因此 Delete _ Buffer 对 应 UPDATE 操 作 的 第 一 个 过 程 ， 即 将 记录 标记 
为 删除 。Purge Buffer 对 应 UPDATE 操 作 的 第 二 个 过 程 ， 即 将 记录 真正 的 
删除 。 同 时 ，InnoDB 存 储 引 擎 提供 了 参数 innodb_change_buffering， 用 
来 开局 各 种 Buffer 的 选项 。 访 参数 可 选 的 值 为 : inserts、deletes、 
purges、changes、all、none。inserts、deletes、purges 就 是 前 面 讨论 过 的 


三 种 情况 。changes 表 示 启 用 inserts 和 deletes，all 表 示 启 用 所 有 ，none 表 














示 都 不 启用 。 该 参数 默认 值 为 all。 


从 InnoDB 1.2.x 版 本 开始 ， 可 以 通过 参数 
innodb_change_buffer_max_size 来 控制 Change ”Buffer 最 大 使 用 内 存 的 数 


里 : 





mysql- SHOW VARIABLES LIKE' vies: . change buffer max size'*6; 
nri —— 
Variable name:innodb change | bürfer .max size 

Value:25 

1 row in set(0.00 sec) 





innodb change buffer max_size 值 默认 为 25， 表 示 最 多 使 用 1/4 的 组 
冲 池 内 存 空间 。 而 需要 注意 的 是 ， 该 参数 的 最 大 有 效 值 为 50。 


在 MySQL 5.5 版 本 中 通过 命令 SHOW ENGINE INNODB STATUS, 
可 以 观察 到 类 似 如 下 的 内 容 : 








mysql- SHOW ENGINE INNODB STATUS\G; 


kkkkkkkkkkkkkkkkkkkkkkkkkkkę pg KO ko ke koe ke ek ek ko ke ek e ee 


Ibuf:size 1,free list len 34397,seg size 34399,10875 merges 
merged operations: 

insert 20462,delete mark 20158,delete 4215 

discarded operations: 

insert 0,delete mark 0,delete 0 





可 以 看 到 这 里 显示 了 merged operationsflldiscarded operation, Jf H. 

面具 体 显 示 Change Buffer 中 每 个 操作 的 次 数 。insert 表 示 Insert 

Buffer; delete markz&zr Delete Buffer; delete 表 示 Purge Buffer; discarded 

operations 表 示 当 Change _ Buffer 发 后 merge 时 ， 表 已 经 被 删除 ， 此 时 就 无 
需 再 将 记录 合并 (merge) 到 辅助 索引 中 了 。 


3.Insert Buffer 的 内 部 实现 


通过 前 一 个 小 市 读者 应 该 已 经 知道 了 Insert Buffer 的 使 用 场景 ， 即 非 
un 辅助 索引 的 插入 操作 。 但 是 对 于 Insert Buffer 具 体 是 什么 ， 以 及 内 部 
怎么 实现 可 能 依然 模糊 ， 这 正 是 本 节 所 要 阐述 的 内 容 。 


可 能 令 绝 大 部 分 用 户 感到 吃惊 的 是 ，Insert Buffer 的 数据 结构 是 一 棵 
BR. 在 MySQL 4.1 之 前 的 版 本 中 每 张 表 有 一 棵 Insert Buffer B+ 树 。 而 
在 现在 的 版 本 中 ， 全 局 只 有 一 棵 Insert Buffer B+ 树 ， 负 责 对 所 有 的 表 的 














辅助 索引 进行 Insert Buffer。 而 这 棵 B+ 树 存放 在 共享 表 空 间 中 ， 默 认 也 
束 是 ibdatal 中 。 因 此 ， 试 图 通过 独立 表 空 间 ibd 文 件 恢复 表 中 数据 时 ， 
往往 会 导致 CHECK TABLE 失 败 。 这 是 因为 表 的 辅助 索引 中 的 数据 可 能 
还 在 Insert Buffer 中 ， 也 就 是 共享 表 空 间 中 ， 上 所 以 通过 ibd 文 件 进行 恢 复 
后 ， 还 需要 进行 REPAIR TABLE 操 作 来 重建 表 上 所 有 的 辅助 索引 。 


Insert Buffer 是 一 棵 B+ 树 ， 因 此 其 也 由 叶 节 点 和 非 叶 节 点 组 成 。 非 
叶 节 点 存放 的 是 查询 的 search key 〈 键 值 ) ， 其 构造 如 图 2-3 所 示 。 


图 2-3 Insert Buffer 非 叶 节 点 中 的 search key 


search key 一 共 占 用 9 个 字 节 ， 其 中 space 表 示 待 插入 记录 所 在 表 的 表 
空间 id， 在 InnoDB 存 储 引擎 中 ， 每 个 表 有 一 个 唯一 的 space ”id， 可 以 通 
过 space id 查询 得 知 是 哪 张 表 。space 占 用 4 字 节 。marker 占 用 1 字 节 ， 它 
是 用 来 兼容 老 版 本 的 Insert Buffer。offset 表 示 页 所 在 的 偏 移 量 ， 占 用 4 字 
dis 




















当 一 个 辅助 索引 要 插入 到 页 (space, offset) 时 ， 如 果 这 个 页 不 在 
绥 冲 池 中 ， 那 么 InnoDB 存 储 引 擎 首先 根据 上 述 规则 构造 一 个 search 
key， 接 下 来 查询 Insert Buffer 这 棵 B+ 树 ， 然 后 再 将 这 条 记录 插入 到 Insert 
Buffer B+ 树 的 叶子 节点 中 。 


对 于 插入 到 Insert Buffer B+ 树叶 子 节点 的 记录 (如 图 2-4 所 示 ) ， 并 
不 是 直接 将 待 插入 的 记录 插入 ， 而 是 需要 根据 如 下 的 规则 进行 构造 : 





es TTT 


secondary index record 
图 2-4 Insert Buffer 叶 子 节点 中 的 记录 
space、marker、page_no 字 段 和 之 前 非 叶 节点 中 的 含义 相同 ， 一 共 


占用 9 字 节 。 第 4 个 字段 metadata 占 用 4 字 市 ， 其 存储 的 内 容 如 表 2-2 所 
Ze 


ALL ladle RA 


à i 7 1 
BUE REC OFFSET COUNT 
BUF REC OFFSET TYPE | 
BUF REC OFFSET FLAGS | 


IBUF_REC_OFFSET_COUNT 是 保存 两 个 字 节 的 整数 ， 用 来 排序 每 
个 记录 进入 Insert Buffer 的 顺序 。 因 为 从 InnoDB1.0.x 开 始 支 持 Change 
Buffer， 所 以 这 个 值 同样 记录 进入 Insert Buffer 的 顺序 。 通 过 这 个 顺序 回 
放 (replay) 才能 得 到 记录 的 正确 值 。 


从 Insert Buffer 叶 子 节点 的 第 5 列 开始 ， 就 是 实际 插入 记录 的 各 个 字 
段 了 。 因 此 较 之 原 插 入 记录 ，Insert Buffer B+ 树 的 叶子 节点 记录 需要 额 
外 13 字 节 的 开销 。 


因为 启用 Insert Buffer 索 引 后 ， 辅 助 索引 页 (space, page noO 中 的 
记录 可 能 被 插入 到 Insert Buffer B+ 树 中 ， 所 以 为 了 保证 每 次 Merge Insert 
Buffer 页 必须 成 功 ， 还 需要 有 一 个 特殊 的 页 用 来 标记 每 个 辅助 索引 页 

(space, page_no) 的 可 用 空间 。 这 个 页 的 类 型 为 Insert Buffer Bitmap. 








每 个 msert Buffer Bitmap 页 用 来 追踪 16384 个 辅助 索引 页 ， 
256 个 区 (Extent) 。 每 个 Insert Buffer Bitmap 页 都 在 16384 个 页 a 第 三 : 
页 中 。 关 于 Insert Buffer Bitmap 页 的 作用 会 在 下 一 小 市 中 详细 介 


每 个 辅助 索引 页 在 Insert Buffer Bitmap 页 中 占用 4 位 (bit) ， 由 表 2- 
3 中 的 三 个 部 分 组 成 。 
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à uh (bi A 
AN RU "DR 
METTI C 
BUF BITMAP FREE 】 | ORDRE (FH) 
QATAR 
0 ERRRHNST 1B 
BUF BITMAP BUFFERED EN LAE CRGA HE Iset Buller B+ 由 
BUF BITMAP IU Eg nL net Buter BY 
4.Merge Insert Buffer 


通过 前 面 的 小 节 读 者 应 该 已 经 知道 了 Insert/Change Buffer — P 
B+ 树 。 知 需要 实现 插入 记录 的 辅助 索引 页 不 在 绥 冲 池 中 ， 那 么 需要 将 
辅助 索引 记录 首先 插入 到 这 棵 B+ 树 中 。 但 是 Insert ”Buffer 中 的 记录 何 时 
合并 Cmerge) 到 真正 的 辅助 索引 中 呢 ? 这 是 本 小 节 需 要 关注 的 重点 。 

概括 地 说 ，Merge Insert Buffer 的 操作 可 能 发 生 在 以 下 几 种 情况 下 : 

口 辅助 索引 页 被 读 取 到 缓冲 池 时 ; 


OQ Insert Buffer Bitmap 页 追踪 到 该 辅助 索引 页 已 无 可 用 空间 时 ; 








U Master Thread. 


38 — Mir OLA EDR 5] BIZ AY, ol) Qe FE UT 1E 
常 的 SELECT 查询 操作 ， 这 时 需要 检查 Insert Buffer Bitmap 页 ， 然 后 确认 
该 辅助 索引 页 是 否 有 记录 存放 于 Insert Buffer B+ 树 中 。 若 有 ， 则 将 Insert 
Buffer B+ 树 中 该 页 的 记录 插入 到 该 辅助 索引 页 中 。 可 以 看 到 对 该 页 多 次 
人 的 辅助 索引 页 中 ， 因 此 性 能 会 有 

晶 提 高 。 


Insert Buffer Bitmap 页 用 来 奶 踪 每 个 辅助 索引 页 的 可 用 空间 ， 并 至 
少 有 1/32 页 的 空间 。 寿 插入 辅助 索引 记录 时 检测 到 插入 记录 后 可 用 空间 
会 小 于 1/32 页 ， 则 会 强制 进行 一 个 合并 操作 ， 即 强制 读 取 辅 助 索引 页 ， 
将 Insert Buffer B+ 树 中 该 页 的 记录 及 待 插入 的 记录 插入 到 辅助 索引 页 
中 。 这 束 是 上 述 所 说 的 第 二 种 情况 。 


还 有 一 种 情况 ， 之 前 在 分 析 Master Thread 时 曾 讲 到 ， 在 Master 
Thread 线 程 中 每 秒 或 每 10 秒 会 进行 一 次 Merge Insert Buffer 的 操作 ， 不 同 
之 处 在 于 每 次 进行 merge 操作 的 页 的 数量 不 同 。 


在 Master Thread 中 ， 执 行 merge 操 作 的 不 止 是 一 个 页 ， 而 是 根据 
srv_innodb_io_capactiy 的 百分比 来 决定 真正 要 合并 多 少 个 辅助 索引 页 。 
但 InnoDB 存 储 引 擎 又 是 根据 怎样 的 算法 来 得 知 需要 合并 的 辅助 索引 页 


呢 ? 


























在 Insert Buffer B+ 树 中 ， 辅 助 索 引 页 根据 (space, offset) 都 已 排序 
好 ， 故 可 以 根据 Cspace, offset) 的 排序 顺序 进行 页 的 选择 。 然 而 ， 对 
于 Insert ”Buffer 页 的 选择 ，InnoDB 存 储 引 擎 并 非 采用 这 个 方式 ， 它 随机 
地 选择 Insert Buffer B+ 树 的 一 个 页 ， 读 取 该 页 中 的 space 及 之 后 所 需要 数 
量 的 页 。 该 算法 在 复杂 情况 下 应 有 更 好 的 公平 性 。 同 时 ， 若 进行 merge 
时 ， 要 进行 merge 的 表 已 经 被 删除 ， 此 时 可 以 直接 丢弃 已 经 被 
Insert/Change Buffer 的 数据 记录 。 




















2.6. ”两 次 写 


如 果 说 Insert ”Buffer 带 给 InnoDB 存 储 引 擎 的 是 性 能 上 的 提升 ， 那 么 
doublewrite (两 次 写 ) 带 给 InnoDB 存 储 引 擎 的 是 数据 页 的 可 靠 性 。 


当 发 生 数 据 库 宕 机 时 ， 可 能 InnoDB 存 储 引 擎 正在 写 入 某 个 页 到 表 
中 ， 而 这 个 页 只 写 了 一 部 分 ， 比 如 16KB 的 页 ， 只 写 了 前 4KB， 之 后 就 
发 生 了 宕 机 ， 这 种 情况 被 称 为 部 分 写 失效 (partial page write) . 在 
InnoDB 存 储 引 警 未 使 用 doublewrite 技 术 前 ， 兽 经 出 现 过 因为 部 分 写 失 效 
而 导致 数据 丢失 的 情况 。 


有 经 验 的 DBA 也 许 会 想 ， 如 果 发 后 写 失效 ， 可 以 通过 重 做 日 志 进 行 
恢复 。 这 是 一 个 办 法 。 但 是 必须 清楚 地 认识 到 ， 重 做 日 志 中 记录 的 是 对 
页 的 物理 操作 ， 如 偏 移 量 800， 写 'aaaa'" 记 录 。 如 果 这 个 页 本 身 己 经 发 生 
了 损坏 ， 再 对 其 进行 重 做 是 没有 意义 的 。 这 就 是 说 ， 在 应 用 Capply) 
重 做 日 志 前 ， 用 户 需 要 一 个 页 的 副本 ， 当 写 入 失效 发 生 时 ， 先 通过 页 的 
副本 来 还 原 该 页 ， 再 进行 重 做 ， 这 束 是 doublewrite。 在 InnoDB 存 储 引擎 
中 doublewrite 的 体系 架构 如 图 2-5 所 示 。 

















doublewrite buffer 
(2MB) 


doublewrite | doublewrite 
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图 2-5 InnoDB 存 储 引 警 doublewrite 架 构 


doublewrite 由 两 部 分 组 成 ， 一 部 分 是 内 存 中 的 doublewrite buffer, 
大 小 为 2MB， 男 一 部 分 是 物理 磁盘 上 共享 表 空 间 中 连续 的 128 个 页 ， 即 2 
个 区 Cextent) ， 大 小 同样 为 2MB。 在 对 缓冲 池 的 脏 页 进行 刷新 时 ， 并 
不 直接 写 磁盘 ， 而 是 会 通过 memcpy 函 数 将 脏 页 先 复制 到 内 存 中 的 
doublewrite buffer， 之 后 通过 doublewrite buffer 再 分 两 次 ， 每 次 1MB 顺 序 
地 写 入 共享 表 空 间 的 物理 磁盘 上 ， 然 后 马上 调用 fsync 函 数 ， 同 步 磁 盘 ， 
避免 缓冲 写 带 来 的 问题 。 在 这 个 过 程 中 ， 因 为 doublewrite 页 是 连续 的 ， 
因此 这 个 过 程 是 顺序 写 的 ， 开 销 并 不 是 很 大 。 在 完成 doublewrite 页 的 写 
入 后 ， 再 将 doublewrite ”buffer 中 的 页 写 入 各 个 表 空 间 文 件 中 ， 此 时 的 写 
入 则 是 离散 的 。 可 以 通过 以 下 命令 观察 到 doublewrite 运 行 的 情况 : 




















ORO EORR GEORGIO GEO] ppt eoe 
Variable name:Innodb dblwr pages written 

Value:6325194 

OO OO KO | peer 
Variable name:Innodb dblwr writes 
Value:100399 

2 rows in set(0.00 sec) 








可 以 看 到 ，doublewrite 一 共 写 了 6 325 194 个 页 ， 但 实际 的 写 入 次 数 
为 100 399， 基 本 上 符合 64 : 1。 如 果 发 现 系统 在 高 峰 时 的 
Innodb_dblwr_pages_written:Innodb_dblwr_writes 远 小 于 64 : 1， 那 么 可 以 
说 明 系 统 写 入 压力 并 不 是 很 高 。 


如 果 操 作 系 统 在 将 页 写 入 磁盘 的 过 程 中 发 生 了 裔 误 ， 在 恢复 过 程 
中 ，InnoDB 存 储 引 擎 可 以 从 共享 表 空 间 中 的 doublewrite 中 找到 该 页 的 一 
个 副本 ， 将 其 复制 到 表 空 间 文 件 ， 再 应 用 重 做 日 志 。 下 面 显示 了 一 个 由 
doublewrite 进 行 恢复 的 情况 : 





090924 11:36:32 mysqld restarted 

090924 11:36:33 InnoDB:Database was not shut down normally! 
InnoDB:Starting crash recovery. 

InnoDB:Reading tablespace information from the.ibd files... 
InnoDB:Crash recovery may have failed for some.ibd files! 
InnoDB:Restoring possible half-written data pages from the doublewrite 
InnoDB:buffer... 





4 fUBMySQLEZI Fit, AXES; SHOW GLOBAL STATUS 
rPInnodb buffer pool pages flushed7P ERIR “4 Bip JA Zz pati F pl 39r BR 
盘 页 的 数量 。 根 据 之 前 的 介绍 ， 用 户 应 该 了 解 到 ， 在 默认 情况 下 所 有 页 
的 刷新 首先 都 需要 放 入 到 doublewrite 中 ， 因 此 该 变量 应 该 和 
Innodb dblwr pages written—$X. JAMI tEMySQL 5.5.24 版 本 之 前 ， 
Innodb_buffer_pool_pages_flushed 总 是 为 Innodb_dblwr_pages_written 的 2 








倍 ， 而 此 Bug 直 到 MySQL5.5.24 才 被 修复 。 因 此 用 户 知 需要 统计 数据 库 
在 生产 环境 中 写 入 的 量 ， 最 安全 的 方法 还 是 根据 
Innodb_dblwr_pages_written 来 进行 统计 ， 这 在 所 有 版 本 的 MySQL 数 据 库 
中 都 是 正确 的 。 


参数 skip_innodb_doublewrite 可 以 禁止 使 用 doublewrite 功 能 ， 这 时 可 
能 会 发 生前 面 提 及 的 写 失 效 问题 。 不 过 如 果 用 户 有 多 个 从 服务 器 (slave 
server) ， 需 要 提供 较 快 的 性 能 (如 在 slaves erver 上 做 的 是 RAID0) , tH 
许 启 用 这 个 参数 是 一 个 办 法 。 不 过 对 于 需要 提供 数据 高 可 靠 性 的 主 服务 
as (master server) ， 任 何 时 候 用 户 都 应 确保 开启 doublewrite 功 能 。 


注意 ”有些 文件 系统 本 身 就 提供 了 部 分 写 失 效 的 防范 机 制 ， 如 ZFS 
文件 系统 。 在 这 种 情况 下 ， 用 户 束 不 要 启用 doublewrite 了 。 





2.6.3 Hig WIA RS 


哈 希 〈hash) 是 一 种 非常 快 的 碍 找 方法 ， 在 一 般 情 况 下 这 种 查找 的 
时 间 复 杂 度 为 01)， 即 一 般 仅 需要 一 次 查找 就 能 定位 数据 。 而 B+ 树 的 奋 
找 次 数 ， 取 决 于 B+ 树 的 高 度 ， 在 生产 环境 中 ，B+ 树 的 高 度 一 般 为 3 一 4 
层 ， 故 需要 3 一 4 次 的 查询 。 


InnoDB 存 储 引 擎 会 监控 对 表 上 各 索引 页 的 查询 。 如 果 观 察 到 建立 
哈 希 索引 可 以 融 来 速度 提升 ， 则 建立 哈 希 索引 ， 称 之 为 目 适 应 哈 希 索 引 
(Adaptive Hash Index, AHI) 。AHI 是 通过 缓冲 池 的 B+ 树 页 构造 而 
来 ， 因 此 建立 的 速度 很 快 ， 而 且 不 需要 对 整 张 表 构建 哈 希 索 引 . 
InnoDB 存 储 引 擎 会 自动 根据 访问 的 频率 和 模式 来 自动 地 为 菜 些 热 点 页 
EETRI 


AHI 有 一 个 要 求 ， 即 对 这 个 页 的 连续 访问 模式 必须 是 一 样 的 。 例 如 
oo ee 


LY WHERE a=xxx 











LY WHERE a=xxx and b=xxx 


访问 模式 一 样 指 的 是 查询 的 条 件 一 样 ， 知 交 普 进行 上 述 两 种 查询 ， 
那么 monDB 存 储 引 擎 不 会 对 该 页 构造 AHI。 此 外 AHI 还 有 如 下 的 要 求 : 


口 以 该 模式 访问 了 100 次 








口 页 通过 该 模式 访问 了 N 次 ， 其 中 N= 页 中 记录 *1/16 


根据 InnoDB 存 储 引擎 官方 的 文档 显示 ， 启 用 AHI 后 ， 读 取 和 写 入 速 
度 可 以 提高 2 倍 ， 辅 助 索引 的 连接 操作 性 能 可 以 提高 5 倍 。 军 无 疑问 ， 
AHI 是 非常 好 的 优化 模式 ， 其 设计 思想 是 数据 库 自 优 化 的 (self- 
tuning) ， 即 无 需 DBA 对 数据 库 进 行人 为 调整 。 


通过 命令 SHOW ENGINE INNODB STATUS 可 以 看 到 当前 AHI 的 使 
用 状况 : 











mysql- SHOW ENGINE INNODB STATUS\G; 


ORO ORO ROO KO REOR GO KO OR GGG] po CR OR Ro Ro e OR RR o e e ee e 


Status: 


Ibuf:size 2249,free list len 3346,seg size 5596, 
374650 inserts,51897 merged recs,14300 merges 

Hash table size 4980499,node heap has 1246 buffer(s) 
1640.60 hash searches/s,3709.46 non-hash searches/s 





现在 可 以 看 到 AHI 的 使 用 信息 了 ， 包 括 AHI 的 大 小 、 使 用 情况 、 
秒 使 用 AHI 搜 索 的 情况 。 值 得 注意 的 是 ， 哈 希 索引 只 能 用 来 搜索 等 值 的 
查询 ， 如 SELECT*FROM table WHERE index_col='xxx'。 而 对 于 其 他 碍 
找 类 型 ， 如 范围 查找 ， 使 用 哈 希 索引 的 ， 因 此 这 里 出 现 了 non- 
hash searches/s 的 情况 。 通 过 hash searches:non-hash searches 可 以 大 概 了 解 
使 用 哈 希 索引 后 的 效率 。 


由 于 AHI 是 由 InnoDB 存 储 引 擎 控制 的 ， 因 此 这 里 的 信息 只 供用 户 参 
考 。 不 过 用 户 可 以 通过 观察 SHOW ENGINE INNODB STATUS 的 结果 及 
参数 innodb E DNE hash_index 来 考虑 是 禁用 或 启动 此 特性 ， 默 认 AHI 
为 开启 状态 





2.6.4 ”异步 IO 


为 了 提高 磁盘 操作 性 能 ， 当 前 的 数据 库 系 统 都 采用 异步 
IO (Asynchronous IO, AIO) 的 方式 来 处 理 磁 盘 操作 。InnoDB 存 储 引 擎 
亦 是 如 此 。 


与 AIO 对 应 的 是 Sync IO， 即 每 进行 一 次 IO 操作 ， 需 要 等 待 此 次 操作 
结束 才能 继续 接 下 来 的 操作 。 但 是 如 果 用 户 发 出 的 是 一 条 索引 扫描 的 查 
询 ， 那 么 这 条 SQL 查询 语句 可 能 需要 扫描 多 个 索引 页 ， 也 就 是 需要 进行 
多 次 的 IO 操作 。 在 每 扫描 一 个 页 并 等 待 其 完成 后 再 进行 下 一 次 的 扫描 ， 
这 是 没有 必要 的 。 用 户 可 以 在 发 出 一 个 IO 请 求 后 立即 再 发 出 另 一 个 IO 请 
求 ， 当 全 部 IO 请 求 发 送 完 毕 后 ， 等 等 所 有 IO 操作 的 完成 ， 这 了 束 是 AIO。 


AIO 的 另 一 个 优势 是 可 以 进行 IO Merge 操 作 ， 也 就 是 将 多 个 IO 合并 
为 1 个 IO， 这 样 可 以 提高 IOPS 的 性 能 。 例 如 用 户 需 要 访问 页 的 《space， 
page no) 为 : 




















(8, 6) 、 (8, 7, (8, 8) 





每 个 页 的 大 小 为 16KB， 那 么 同步 IO 需要 进行 3 次 IO 操作 。 而 AIO 会 
判断 到 这 三 个 页 是 连续 的 〈 显 然 可 以 通过 Cspace, page no) 得 知 ) 。 
因此 AIO 底 层 会 发 送 一 个 IO 请 求 ， 从 (8, 6) 开始 ， 读 取 48KB 的 页 。 


若 通 过 Linux 操 作 系统 下 的 iostat 命 令 ， 可 以 通过 观察 rrqm/s 和 
wrqm/s， 例 如 : 





avg-cpu:%user%nice%system%iowait%steal%idle 
4.70 0.00 1.60 13.20 0.00 80.50 

Device:rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm%util 
sdc 3905.67 172.00 6910.33 466.67 168.81 18.15 51.91 19.17 2.59 0.13 97.73 





在 InnoDB1.1.x 之 前 ，AIO 的 实现 通过 ImnoDB 存 储 引 警 中 的 代码 来 
模拟 实现 。 而 从 InnoDB 1.1.x 开 始 (InnoDB Plugin 不 支持 ) ， 提 供 了 内 
核 级 别 AIO 的 文 持 ， 称 为 Native AIO。 因 此 在 编译 或 者 运行 该 版 本 
MySQL 时 ， 需 要 libaio 库 的 文 持 。 知 没有 则 会 出 现 如 下 的 提示 : 





/usr/local/mysql/bin/mysqld:error while loading shared libraries:libaio.so.1:cannot open shared object file:No such file 
or directory 





需要 注意 的 是 ，Native AIO 需 要 操作 系统 提供 支持 。Windows 系 统 
和 Linux 系 统 都 提供 Native AIO 文 持 ， 而 Mac OSX 系 统 则 未 提供 。 因 此 在 
这 些 系统 下 ， 依 旧 只 能 使 用 原 模 拟 的 方式 。 在 选择 MySQL 数 据 库 服务 
器 的 操作 系统 时 ， 需 要 考虑 这 方面 的 因素 。 


参数 innodb_use_native_aio 用 来 控制 是 否 启 用 Native AIO， 在 Linux 
操作 系统 下 ， 默 认 值 为 ON: 








mysql>SHOW VARIABLES LIKE'innodb use native aio'*6; 


JÓREOOK KOROROIOROGIOOIGIORGIOR ROIGROGIOGIGOK d. pf Re Roo Ro RO KORR Ro Ree 


e:0N 
1 row in set(0.00 sec) 





用 户 可 以 通过 开启 和 关闭 Native AIO 功能 来 比较 InnoDB 性 能 的 所 
升 。 官 方 的 测试 显示 ， 启 用 Native AIO， 恢 复 速 度 可 以 提高 75%。 


在 InnoDB 存 储 引擎 中 ，read ” ahead 方式 的 读 取 都 是 通过 AIO 完 成 ， 
脏 页 的 刷新 ， 即 磁盘 的 写 入 操作 则 全 部 由 AIO 完 成 。 


2.6.5 ”刷新 邻接 页 


InnoDB 存 储 引擎 还 提供 了 Flush Neighbor Page〈 刷 新 邻接 页 ) 的 特 
性 。 其 工作 原理 为 : 当 刷 新 一 个 脏 页 时 ，InnoDB 存 储 引 擎 会 检测 该 页 
所 在 区 (extent〉 的 所 有 页 ， 如 果 是 脏 页 ， 那 么 一 起 进行 刷新 。 这 样 做 
的 好 处 显而易见 ， 通 过 AIO 可 以 将 多 个 IO 写 入 操作 合并 为 一 个 IO 操作 ， 
故 该 工作 机 制 在 传统 机 械 磁 盘 下 有 着 显著 的 优势 。 但 是 需要 考虑 到 下 面 


两 个 问题 : 


口 是 不 是 可 能 将 不 怎么 脏 的 页 进行 了 写 入 ， 而 该 页 之 后 又 会 很 快 变 
成 脏 页 ? 


口 固态 硬盘 有 着 较 高 的 IOPS， 是 否 还 需要 这 个 特性 ? 


为 此 ，InnoDB 存 储 引 擎 从 1.2.x 厂 本 开始 提供 了 参数 
innodb_flush_neighbors， 用 来 控制 是 否 司 用 该 特性 。 对 于 传统 机 械 人 硬盘 
建议 局 用 该 特性 ， 而 对 于 固态 便 入 有 痢 超 高 IOPS 性 能 的 磁 往 ， 则 建议 将 
该 参数 设置 为 0， 即 关闭 此 特性 。 

















2.7 ”局 动 、 关 闭 与 恢复 


InnoDB 是 MySQL 数 据 库 的 存储 引擎 之 一 ， 因 此 InnoDB 存 储 引 擎 的 
局 动 和 关闭 ， 更 准确 的 是 指 在 MySQL 实 例 的 局 动 过程 中 对 InnoDB 存 储 
引擎 的 处 理 过 程 。 


在 关闭 时 ， 参 数 innodb_fast_ shutdown 影 响 着 表 的 存储 引擎 为 
InnoDB 的 行为 。 该 参数 可 取 值 为 0(、1、2， 默 认 值 为 1。 


口 0 表示 在 MySQL 数 据 库 关 闭 时 ，InnoDB 需 要 完成 所 有 的 full purge 
和 merge insert buffer， 并 且 将 所 有 的 脏 页 刷新 回 磁盘 。 这 需要 一 些 时 
间 ， 有 时 甚至 需要 几 个 小 时 来 完成 。 如 果 在 进行 InnoDB 升 级 时 ， 必 须 
将 这 个 参数 调 为 0， 然 后 再 关闭 数据 库 。 


口 1 是 参数 innodb_fast_shutdown 的 默认 值 ， 表 示 不 需要 完成 上 述 的 
full purge 和 merge insert buffer 操 作 ， 但 是 在 缓冲 池 中 的 一 些 数据 脏 页 还 
Fe x Rr ERARE - 


口 2 表示 不 完成 full purge 和 merge insert buffer 操 作 ， 也 不 将 缓冲 池 中 
的 数据 脏 页 写 回 磁盘 ， 而 是 将 日 志 都 号 入 日 志文 件 。 这 样 不 会 有 任何 事 
务 的 丢失 ， 但 是 下 次 MYSQL 数据 库 局 动 时 ， 会 进行 恢复 操作 


(recovery) 。 


当 正 常 关闭 MySQL 数 据 库 时 ， 下 次 的 启动 应 该 会 非常 “正常 >。 但 是 
如 果 没 有 正常 地 关闭 数据 库 ， 如 用 kill 命 令 关闭 数据 库 ， 在 MySQL 数 据 
库 运行 中 重启 了 服务 器 ， 或 者 在 关闭 数据 库 时 ， 将 参数 
innodb_fast_shutdown 设 为 了 2 时 ， 下 次 MySQL 数 据 库 启 动 时 都 会 对 
InnoDB 存 储 引 擎 的 表 进行 恢复 操作 。 


参数 innodb_force_recovery 影 响 了 整个 InnoDB 存 储 引 擎 恢复 的 状 
况 。 该 参数 值 默认 为 0， 代 表 当 发 生 需 要 恢复 时 ， 进 行 所 有 的 恢复 操 
作 ， 当 不 能 进行 有 效 恢 复 时 ， 如 数据 页 发 生 了 corruption，MySQL 数 据 
库 可 能 发 生 宕 机 Ccrash) ， 并 把 错误 写 入 错误 日 志 中 去 。 


但 是 ， 在 某 些 情况 下 ， 可 能 并 不 需要 进行 完整 的 恢复 操作 ， 因 为 用 
户 自己 知道 怎么 进行 恢复 。 比 如 在 对 一 个 表 进 行 alter table 操 作 时 发 生意 
外 了 ， 数 据 库 重 启 时 会 对 InnoDB 表 进行 回 深 操 作 ， 对 于 一 个 大 表 来 说 


















































这 需要 很 长 时 间 ， 可 能 是 几 个 小 时 。 这 时 用 户 可 以 自行 进行 恢复 ， 如 可 
以 把 表 删 除 ， 从 备份 中 重新 导入 数据 到 表 ， 可 能 这 些 操 作 的 速度 要 远 远 
快 于 回 深 操 作 。 


参数 innodb_force_recovery 还 可 以 设置 为 6 个 非 零 值 ， 1 一 6。 大 的 数 
字 表 示 包 含 了 前 面 所 有 小 数字 表示 的 影响 。 有 具体 情况 如 下 : 


D1(SRV_FORCE_IGNORE_CORRUPT): 忽略 检查 到 的 corrupt 页 。 


口 2(SRV_FORCE_NO_BACKGROUND): 阻止 Master Thread 线 程 的 
运行 ， 如 Master Thread 线 程 需要 进行 full purge 操 作 ， 而 这 会 导致 crash。 


D3(SRV_FORCE_NO_TRX_UNDO): 不 进行 事务 的 回 滚 操作 。 
口 4SRV_FORCE_NO_IBUF_MERGE): 不 进行 插入 缓冲 的 合并 操 


D5(SRV_FORCE_NO_UNDO_LOG_SCAN): 不 查看 撤销 日 志 
(Undo Log) ，InnoDB 存 储 引 擎 会 将 未 提交 的 事务 视 为 已 提交 。 








DQe(SRV. FORCE NO LOG REDO): 不 进行 前 滚 的 操作 。 


需要 注意 的 是 ， 在 设置 了 参数 innodb_force_recovery 大 于 0 后 ， 用 户 
可 以 对 表 进 行 select、create 和 drop 操 作 ， 但 insert、update 和 delete 这 类 
DML 操 作 是 不 允许 的 。 


现在 来 做 一 个 实验 ， 模 拟 故 障 的 发 生 。 在 第 一 个 会 话 中 
(session) ， 对 一 张 接 近 1 000 万 行 的 InnoDB 存 储 引 擎 表 进 行 更 新 操 
作 ， 但 是 完成 后 不 要 马上 提交 : 














mysql>START TRANSACTION; 
uery OK,0 rows affected(0.00 sec) 
> rofile SET ssword=''; 
Query OK,9587770 rows affected(7 min 55.73 sec) 
Rows matched:9999248 Changed:9587770 Warnings:0 





START TRANSACTION 语句 开启 了 事务 ， 同 时 防止 了 自动 提交 
Cauto commit) 的 发 生 ，UPDATE 操 作 则 会 产生 大 量 的 UNDO 日 志 
(undo log) 。 这 时 ， 人 为 通过 Kill 命令 杀 掉 MySQL 数 据 库 服 务 器 : 





[rootünineyou0O-43— ]#ps-ef|grep mysqld 


root 28007 al 0 13:40 pts/1 00:00:00/bin/sh./bin/mysqld safe--datadir-/usr/local/mysql/data--pid- 
file-/usr/local/mysql/data/nineyou0O-43.pid 
mysql 28045 28007 42 13:40 pts/1 00:04:23/usr/1local/mysql/bin/mysqld--basedir-/usr/local/mysql-- 


datadir=/usr/local/mysql/data- -user=mysql--pid-file=/usr/local/mysql/data/nineyouO-43.pid--skip-external-locking- -port=3306- - 
socket=/tmp/mysql.sock 

root 28110 26963 © 13:50 pts/11 00:00:00 grep mysqld 

[root@nineyou®-43~]#kill-9 28007 

[rootünineyouO-43—]£Zkill-9 28045 





通过 kill 命 令 可 以 模拟 数据 库 的 宕 机 操作 。 下 次 MYSQL 数据 库 局 动 
时 会 对 之 前 的 UPDATE 事 务 进行 回 深 操 作 ， 而 这 些 信息 都 会 记录 在 错误 
日 志文 件 (默认 后 缀 名 为 err) 中 。 如 果 查 看 错误 日 志文 件 ， 可 得 如 下 结 
果 : 








090922 13:40:20 InnoDB:Started;log sequence number 6 2530474615 

InnoDB:Starting in background the rollback of uncommitted transactions 

090922 13:40:20 InnoDB:Rolling back trx with id © 5281035,8867280 rows to undo 

InnoDB:Progress in percents:1090922 13:40:20 

090922 13:40:20[Note]/usr/local/mysqgl/bin/mysqld:ready for connections. 

Version:'5.0.45-log'socket:'/tmp/mysql.sock'port:3306 MySQL Community Server(GPL) 

234567289 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 
45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 
88 89 90 91 92 93 94 95 96 97 98 99 100 

InnoDB:Rolling back of trx id © 5281035 completed 

090922 13:49:21 InnoDB:Rollback of non-prepared transactions completed 





可 以 看 到 ， 采 用 默认 的 策略 ， 即 将 innodb_force_recovery 设 为 0， 
InnoDB 会 在 每 次 局 动 后 对 太 生 问题 的 表 进行 恢复 操作 。 通 过 错误 日 志 
文件 ， 可 知 这 次 回 滚 操作 需要 回 滚 8867280 行 记录 ， 差 不 多 总 共 进 行 了 9 
分 钟 。 


再 做 一 次 同样 的 测试 ， 只 不 过 这 次 在 启动 MySQL 数 据 库 前 ， 将 参 
数 innodb_force_recovery 设 为 3， 然 后 观察 InnoDB 存 储 引 擎 是 否 还 会 进行 
回 深 操作 。 查 看 错误 日 志文 件 ， 可 得 : 














090922 14:26:23 InnoDB:Started;log sequence number 7 2253251193 
InnoDB:!!!innodb force recovery is set to 3!!! 

090922 14:26:23[Note]/usr/local/mysql/bin/mysqld:ready for connections. 
Version:'5.0.45-log'socket:'/tmp/mysql.sock'port:3306 MySQL Community Server(GPL) 





这 里 出 现 了 “!”，InnoDB 和 警告 已 经 将 innodb_force_recovery 设 置 为 
3， 不 会 进行 回 深 操 作 了 ， 因 此 数据 库 很 快 启动 完成 了 。 但 是 用 户 应 该 
小 心 当前 数据 库 的 状态 ， 并 仔细 确认 是 否 不 需要 回 深 事 务 的 操作 。 
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本 章 对 InnoDB 存 储 引 擎 及 其 体系 结构 进行 了 概述 ， 先 给 出 了 
InnoDB 存 储 引 擎 的 历史 、InnoDB 存 储 引 擎 的 体系 结构 〈 包 括 后 人 台 线 程 
和 和 内存 结 构 〉; 之 后 又 详细 介绍 了 InnoDB 存 储 引 擎 的 关键 特性 ， 这 些 
特性 使 mnoDB 存 储 引 擎 变 得 更 具 “ 魅 力 ”， 最 后 介绍 了 局 动 和 关闭 
MySQL 时 一 些 配置 文件 参数 对 InnoDB 存 储 引 擎 的 影响 。 


通过 本 章 的 铺垫 ， 读 者 在 学 习 后 面 的 内 容 时 就 会 对 InnoDB 引 擎 理 
解 得 更 深入 和 更 全 面 。 第 3 章 开 始 介绍 MySQL 的 文件 ， 包 括 MySQL 本 吴 
的 文件 和 与 InnoDB 存 储 引擎 本 身 有 关 的 文件 。 之 后 本 书 将 介绍 基于 
InnoDB 存 储 引 擎 的 表 ， 并 揭示 内 部 的 存储 构造 。 














Boe o xd 

本 章 将 分 析 构 成 MySQL 数 据 库 和 InnoDB 存 储 引 擎 表 的 各 种 类 型 文 
件 。 这些 文 件 有 以 下 这 些 。 

口 参数 文件 : 告诉 MySQL 实 例 启动 时 在 哪里 可 以 找到 数据 库 文 
件 ， 并 且 指 定 某 些 初始 化 参数 ， 这 些 参数 定义 了 某 种 内 存 结构 的 大 小 等 
设置 ， 还 会 介绍 各 种 参数 的 类 型 。 

口 日 志文 件 : 用 来 记录 MySQL 实 例 对 某 种 条 件 做 出 响应 时 写 入 的 
文件 ， 如 错误 日 志文 件 、 二 进 制 日 志文 件 、 慢 查询 日 志文 件 、 查 询 日 志 
SEE 

Osocket XF: 当 用 UNIX 域 套 接 字 方式 进行 连接 时 需要 的 文件 。 

Dpid 文 件 : MySQL 实 例 的 进程 ID 文件 。 

OMySQL#e 25 SCF: 用 来 存放 MySQL 表 结构 定义 文件 。 

口 存储 引 警 文件: 因为 MySQL 表 存储 引擎 的 关系 ， 每 个 存储 引擎 


都 会 有 自己 的 文件 来 保存 各 种 数据 。 这 些 存储 引擎 真正 存储 了 记录 和 索 
引 等 数据 。 本 章 主要 介绍 与 InnoDB 有 关 的 存储 引擎 文件 。 
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在 第 1 童 中 已 经 介绍 过 了 ， 当 MySQL 实 例 启 动 时 ， 数 据 库 会 先 去 读 
25 c 用 来 守 找 数据 库 的 各 种 文件 所 在 位 置 以 及 指 定 某 些 
初始 化 参数 ， 1675 SOU a XE XC T AP NIFE 吉 构 有 多 大 等 。 在 默认 情况 
B MySQL SP 2 Fe se RORIHE ce 定 的 位 置 进行 读 取 ， 用 户 只 需 
通过 命令 mysql--helplgrep my.cnf 来 寻找 即 可 。 


MySQL 数 据 库 参 数 文件 的 作用 和 Oracle 数 据 库 的 参数 文件 极其 类 
似 ， 不 同 的 是 ，Oracle 实 例 在 局 动 时 硝 找 不 到 参数 文件 ， 是 不 能 进行 装 
4% (mounO 操作 的 。MySQL 稍 微 有 所 不 同 ，MySQL 实 例 可 以 不 需要 参 
数 文件 ， 这 时 所 有 的 参数 值 取决 于 编译 MYSQL 时 指定 的 默认 值 和 源 代 
码 中 指定 参数 的 默认 值 。 但 是 ， 如 果 MySQL 实 例 在 默认 的 数据 库 目 录 
下 找 不 到 mysql 架 构 ， 则 局 动 同样 会 失败 ， 此 时 可 能 在 错误 日 总 文件 中 
找到 如 下 内 容 : 








090922 16:25:52 LE qld started 

E 19: ve Pu D ee ia a d;log se qu mber 8 2801063211 

InnoDB: Sey is set to AAT 

096922 af A SSTERROR Fa ata aie ett open and lock privilege tables:Table'mysql.host'doesn't exist 
090922 16:25:53 mysq ended 





MySQL 的 mysql 架 构 中 记录 了 访问 该 实例 的 权限 ， 当 找 不 到 这 个 架 
构 时 ，MySQL 实 例 不 会 成 功 启 动 。 


MySQL 数 据 库 的 参数 文件 是 以 文本 方式 进行 存储 的 。 用 户 可 以 直 
接 通 过 一 些 和 常用 的 文本 编辑 软件 (如 vi 和 emacs) 进行 参数 的 修改 。 


311 和 什么 是 参数 


简单 地 说 ， 可 以 把 数据 库 参 数 看 成 一 个 键 / 值 (key/value) 对。 第 2 
章 PEPYV: 了 一 个 对 于 ImnoDB 存 储 引 警 很 重要 的 参数 
innodb buffer pool _size。 如 我 们 将 这 个 参数 设置 为 1G， 即 
innodb_buffer_pool_size=1G。 这 里 的 “ 键 ? 是 
innodb buffer pool size, “ 值 ? 是 1G， 这 融 是 键 值 对 。 可 以 通过 命令 
SHOW VARIABLES 碍 看 数据 库 中 的 所 有 参数 ， 也 可 以 通过 LIKE 来 过 滤 
参数 名 。 从 MySQL 5.1 版 本 开始 ， 还 可 以 通过 information_schema 架 构 下 
的 GLOBAL_VARIABLES 视 图 来 进行 查找 ， 如 下 所 示 。 











mysql >SELECT*FROM 
- >GLOBAL_VARTABLES 
->WHERE VARIABLE NAME LIKE'innodb_buffer%'\G; 


FORO e eee koe koe ede ke ek eee ek 4 pup Rok eek ek e eek ek de dee ke e e ee 


VARIABLE VALUE:1073741824 
1 row in set(0.00 sec) 
mysql1- SHOW VARIABLES LIKE'innodb_buffer%'\G; 


Value:1073741824 
1 row in set(0.00 sec) 








无 论 使 用 哪 种 方法 ， 输 出 的 信息 基本 上 都 一 样 的 ， 只 不 过 通过 视图 
GLOBAL_VARIABLES 需 要 指定 视图 的 列 名 。 推 荐 使 用 命令 SHOW 
21 c9 因为 这 个 命令 使 用 更 为 简单 ， 且 各 版 本 的 MySQL 数 据 库 
支持 。 


Oracle 数 据 库存 在 所 谓 的 隐藏 参数 Cundocumented parameter) ， 以 
供 Oracle“ 内 部 人 十 "使 用 ，SQL Server 也 有 类 似 的 参数 。 有 些 DBA 曾 问 
我 ，MySQL 中 是 否 也 有 这 类 参数 。 我 的 回答 是 : 没有 ， 也 不 需要 。 即 
使 Oracle 和 SQL “Server 中 都 有 些 所 谓 的 隐藏 参数 ， 在 绝 大 多 数 的 情况 
下 ， 这 些 数据 库 厂商 也 不 建议 用 户 在 生产 环境 中 对 其 进行 很 大 的 调整 。 








312 ”参数 类 型 
MySQL 数 据 库 中 的 参数 可 以 分 为 两 类 : 
口 动态 (dynamic) 参数 
口 静 态 (static) 参数 
动态 参数 意味 着 可 以 在 MySQL 实 例 运行 中 进行 更 改 ， 衣 态 参数 说 


明 在 整个 实例 生命 5 周期 内 部 不 得 进行 更 改 ， 就 好 像 是 只 读 Cread only) 
的 。 可 以 通过 SET 命令 对 动态 的 参数 值 进行 修改 ，SET 的 语法 如 下 : 











SET 
| [global|session]system_var_name=expr 
| [@@global. |@@session. |@@]system_var_name=expr 





这 里 可 以 看 到 global 和 session 关 键 字 ， 它 们 表明 该 参数 的 修改 是 基 
于 当前 会 话 还 是 整个 实例 的 生命 周期 。 有 些 动态 参数 只 能 在 会 话 中 进行 
修改 ， 如 autocommit; 而 有 些 参数 修改 完 后 ， 在 整个 实例 生命 周期 中 都 
会 生效 ， 如 binlog_cache_size; 而 有 些 参数 既 可 以 在 会 话 中 又 可 以 在 整 
个 实例 的 生命 周期 内 生效 ， 如 read_buffer_size。 举 例如 下 : 





mysql>SET read buffer size-524288; 

Query OK,0 rows affected(0.00 sec) 

mysql>SELECT@@session. read | bi. size\G; 
JOOOOEOOOOOOOAOOOOOOOOOOOOOEOKX ] | p yy FOUTS ICICI III ICI III I 
@@session.read_buffer_size: ee 

1 row in set(0.00 sec 

mysql-SELECTQQglobal.read | rn size\G; 

KKK KAKKA KKK KKK KK KRKK | pp! POCO ITO IOI IOS IO RIOR ae 
@@global.read_buffer_size: 2053640 

1 row in set(0.00 sec) 





上 述 示 例 中 将 当前 会 话 的 参数 read_buffer size 从 2MB 调 整 为 了 
512KB， 而 用 户 可 以 看 到 全 局 的 read_buffer_size 的 值 仍 然 是 2MB， 也 就 
是 说 如 果 有 男 一 个 会 话 登 录 到 MySQL 实 例 ， 它 的 read_buffer_size 的 值 是 
2MB, 而 不 是 512KB。 这 里 使 用 了 set ”globallsession 来 改变 动态 变量 的 
值 。 用 户 同样 可 以 直接 使 用 SET@@globll@@session 来 更 改 ， 如 下 所 
Z^: 














mysql-sETQGglobal.read buffer size-1048576; 
Query OK,0 rows affected(0.00 sec) 
mysql>SELECT@@session. read | b. size\G; 


3k IK KOK IK IK TOK IO KK IK IK ke ke 4 yy RR RIOR ko koe ke ee ke eek IO k 


@@session.read_buffer_size: ae 


1 row in set(0.00 sec) 
mysql>SELECT@@global.read_buffer_size\G; 
JOOOOOOOOOOOOOOOOOOOOOOOOEOR] | pj CXCOOOOCOOOOOOOOOOIOOOOOROROK 
QQglobal.read buffer size:1048576 

1 row in set(0.00 sec) 





这 次 把 read_buffer_size 全 局 值 更 改 为 1IMB， 而 当前 会 话 的 
read_buffer_size 的 值 还 是 512KB。 这 里 需要 注意 的 是 ， 对 变量 的 全 局 值 
进行 了 修改 ， 在 这 次 的 实例 生命 周期 内 都 有 效 ， 但 MySQL 实 例 本 喘 并 
不 会 对 参数 文件 中 的 该 值 进行 修改 。 也 就 是 说 ， 在 下 次 启动 时 MySQL 
实例 还 是 会 读 取 参 数 文 件 。 知 想 在 数据 库 实 例 下 一 次 局 动 时 该 参数 还 是 
保留 为 当前 修改 的 值 ， 那 么 用 户 必须 去 修改 参数 文件 。 要 想 知 道 
MySQL 所 有 动态 变量 的 可 修改 范围 ， 可 以 参考 MySQL 官方 手册 的 
Dynamic System Variables 的 相关 内 容 。 


对 于 静态 变量 ， 香 对 其 进行 修改 ， 会 得 到 类 似 如 下 错误 : 











mysql>SET GLOBAL datadir-'/db/mysql'; 
ERROR 1238(HY000):Variable'datadir'is a read only variable 





32 日 志文 件 


日 志文 件 记录 了 影响 MYSQL 数据 库 的 各 种 类 型 活动 。MVYSQL 数 据 
库 中 常见 的 日 志文 件 有 : 


口 错误 日 志 (error log) 


口 二 进 制 日 志 (binlog) 





口 慢 查 询 日 志 (slow query log) 
OA Cog) 


这 些 日 志文 件 可 以 帮助 DBA 对 MySQL 数 据 库 的 运行 状态 进行 诊 
断 ， 从 而 更 好 地 进行 数据 库 层 面 的 优化 。 


3.2. RAG 


错误 日 志文 件 对 MySQL 的 启动 、 运 行 、 关 闭 过 程 进行 了 记录 。 
MySQL DBA 在 过 到 问题 时 应 该 首先 查看 该 文件 以 便 定位 问题 。 该 文件 
TD s 息 ， 也 记录 一 些 警 告 信息 或 正确 的 信息 。 用 户 
可 以 通过 命令 SHOW VARIABLES LIKE'log_error' 来 定位 该 文件 ， dii. 

















mysql>SHOW VARIABLES LIKE' B og_error'\G; 
JOS IIISISI ISI ISIIS IS ISIC ISSIGOGE, PW IC eee eeniononiononioeoeoeoer 
Variable e:log e 
M dn e: /m mys sal. da Es -2s ta rgazer.log 
et(9 ec) 
ca gl>s ys stem s a e 
stargaze 





可 以 看 到 错误 文件 的 路 径 和 文件 名 ， 在 默认 情况 下 错 误 文件 的 文件 
名 为 服务 器 的 主机 名 。 如 上 面 看 到 的 ， 该 主机 名 为 stargazer， 所 以 错误 
文件 名 为 startgazer.err。 = tht MySQL E AR EB 正常 启动 时 ， 第 一 个 
必须 查找 的 文件 应 该 就 是 错误 日 志文 件 ， 该 文件 记录 了 错误 信息 ， 能 很 
好 地 指导 用 户 发 现 问题 。 当 数据 库 不 能 重启 时 ， 通 过 查 错误 日 志文 件 可 
以 得 到 如 下 内 容 : 








[root@nineyou0-43 datal#tail-n 50 nineyouO-43.err 

090924 11:31:18 mysqld started 

090924 11:31:18 InnoDB:Started;log sequ uence mber 8 peters 

090924 11:31:19[ERROR]Fatal error:Can't open o d lock privilege tables:Table'mysql.host'doesn't exist 


090924 11:31:19 mysqld ended 





这 里 ， 错 误 Foe ee RA aaa 所 以 局 动 失败 。 
有 时 用 户 可 以 直接 在 错误 日 志文 件 中 得 到 优化 的 帮助 ， 因 为 有 些 营 告 
Cwarning) 很 好 地 说 明了 问题 所 在 。 而 这 时 可 以 不 需要 通过 查看 数据 
库 状 态 来 得 知 ， 例 如 ， 下 面 的 错误 文件 中 的 信息 可 能 告诉 用 户 需 要 增 大 
InnoDB 存 储 引 擎 的 redo log: 











090924 11:39:44 InnoDB:ERROR:the age of the last checkpoint is 9433712, 
InnoDB:which exceeds the log group capacity 9433498. 
InnoDB:If you are using big BLOB or TEXT rows,you must set the 
InnoDB:combined size of log files at least 10 times bigger than the 
InnoDB:largest such row. 
090924 11:40:00 InnoDB:ERROR:the age of the last checkpoint is 9433823, 
InnoDB:which exceeds the log group capacity 9433498. 
InnoDB:If you are using big BLOB or TEXT rows,you must set the 
InnoDB:combined size of log files at least 10 times bigger than the 
InnoDB:largest such row. 
090924 11:40:16 InnoDB:ERROR:the age of the last checkpoint is 9433645, 
InnoDB:which exceeds the log group capacity 9433498. 
InnoDB:If you are using big BLOB or TEXT rows,you must set the 
InnoDB:combined size of log files at least 10 times bigger than the 
InnoDB:largest such row. 














p—MMM——M—M—————————— eo. eee | 


3.2.2 BAW HE 


3.2.1 小 节 提 到 可 以 通过 错误 日 志 得 到 一 些 关 于 数据 库 优 化 的 信息 ， 
而 慢 查 询 日 志 (slow log) ee tan 
从 而 进行 SQL 语句 层面 的 优化 。 例如 ， 可 以 在 MySQL 月 动 时 设 一 个 阅 
值 ， 将 运行 时 间 超 过 该 值 的 所 有 SQL 语句 都 记录 到 慢 碍 询 日 志文 件 中 。 
DBA 每 天 或 每 过 一 段 时 间 对 其 进行 检查 ， 确 认 是 否 有 SQL 语句 需要 进行 
Tit 该 浆 值 可 以 通过 参数 long_query_time 来 设置 ， 默 认 值 为 10， 代 表 
10 秒 。 


在 默认 情况 下 ，MySQL 数 据 库 并 不 启动 慢 查询 日 志 ， 用 户 需要 手 
工 将 这 个 参数 设 为 ON: 

















Serer rere rece Creer TTC Tre X] pup eee eee 
Variable name:long query ti 
Value:10. FERE 

1 row in set(0.00 sec) 

mysq1- SHOW JARTABLES LIKE' logs slow queries'*G; 
JOOOOEOOOOOOOOOOOOOOOOOOOOOOR | pj CRCKODOODOOGODIOOOOOOOOOOROROK 
var n " name:log slow queri i 
Value: 

1 row ik set(0.00 sec) 














这 里 有 两 点 需要 注意 。 首 先 ， 设 置 1ong_query_time 这 个 浆 值 后 ， 
MySQL 数 据 库 会 记录 运行 时 间 超 过 该 值 的 所 有 SQL 语句 ， 但 运行 时 间 正 
好 等 于 long_query_time 的 情况 并 不 会 被 记录 下 。 也 就 是 说 ， 在 源 代 人 码 中 
判断 的 是 大 于 long_query_time， 而 非 大 于 等 于 。 其 次 ， 从 MySQL 5.1 开 
始 ，long_query_time 开 始 以 微 秒 记 录 SQL 语 句 运行 的 时 间 ， 之 前 仅 用 秘 
为 单位 记录 。 而 这 样 可 以 更 精确 地 记录 SQL 的 运行 时 间 ， 供 DBA 分 析 。 
对 DBA 来 说 ， 一 条 SQL 语 句 运行 0.5 秒 和 0.05 秒 是 非常 不 同 的 ， 前 者 可 能 
已 经 进行 了 表 扫 ， 后 面 可 能 是 进行 了 索引 。 


另 一 个 和 慢 查 询 日 志 有 关 的 参数 是 lo € queries not using indexes 
如 果 运 行 的 SQL 语句 没有 使 用 索引 ， 则 MySQL 数 据 库 同样 会 将 这 条 SQL 
语句 记录 到 慢 查 询 日 志文 件 。 首 先 确认 打开 了 


log queries not using indexes: 
































mysql1- SHOW VARIABLES LIKE' vi cur ueries not using indexes'*G; 
JOOOOIOOIOOOOOOOOOOOOOOOOOOOR] SPQ yi IEICE IIIS ICI III I I 
Var aa " name:log queries | AB usi ing indexes 
Value 

1 row. a set(0.00 sec) 





MySQL 5.6.5 版 本 开始 新 增 了 一 个 参数 
log_throttle_queries_not_using_indexes， 用 来 表示 每 分 钟 人 多 许 记录 到 slow 
log 的 且 未 使 用 索引 的 SQL 语 句 次 数 。 该 值 默 认为 0， 表 示 没 有 限制 。 在 
生产 环境 下 ， 寿 没有 使 用 索引 ， 此 类 SQL 语 句 会 频繁 地 被 记录 到 slow 
ne 从 而 导致 slow log 文 件 的 大 小 不 断 增 加 ， 故 DBA 可 通过 此 参数 进行 
配置 。 


DBA 可 以 通过 慢 碍 询 日 志 来 找 出 有 问题 的 SQL 语句 ， 对 其 进行 优 
化 。 然 而 随 着 MySQL 数 据 库 服务 器 运行 时 间 的 增加 ， 可 能 会 有 越 来 越 
多 的 SQL 但 询 补 记录 到 了 慢 查 询 日 志文 件 中 ， 此 时 要 分 析 该 文件 束 显 得 
不 是 那么 简单 和 直观 的 了 。 而 这 时 MySQL 数 据 库 提供 的 mysqldumpslow 
命令 ， 可 以 很 好 地 帮助 DBA 解 决 该 问题 : 














[rootQnh122-190 data]#mysqldumpslow nh122-190-slow.log 

Reading mysql slow query log from nh122-190-slow.log 

Count:11 Time=10.00s(110s)Lock=0.00s(0s)Rows=0.0(0),dbother[dbother ]@localhost 

insert into test.DbStatus select now(),(N-com select)/(N-uptime), (N-com insert)/(N-uptime), (N-com_update)/(N-uptime), (N- 
com delete)/(N-uptime),N-(N/N),N-(N/N), N.N/N, N-N/(N*N),GetCPULoadInfo(N)from test.CheckDbStatus order by check id desc limit N 

Count:653 Time=0.00s(0s)Lock=0.00s(0s)Rows=0.0(0), 9YOUgs_SC[9YOUgs_SC]@[192.168.43.7] 

select custom name one from'low game schema'.'role details'where role id-'S'rse and summarize the MySQL slow query 


log.Options are 
--verbose verbose 
--debug debug 
--help write this text to standard output 
-v verbose 
-d debug 
-S ORDER what to sort by(al,at,ar,c,l,r,t),'at'is default 
al:average lock time 
ar:average rows sent 
at:average query time 
c:count 
l:lock time 
r:rows sent 
t:query time 
-r reverse the sort order(largest last instead of first) 
-t NUM just show the top n queries 
-a don't abstract all numbers to N and strings to'S' 
-n NUM abstract numbers with at least n digits within names 
-g PATTERN grep:only consider stmts that include this string 
-h HOSTNAME hostname of db server for*-slow.log filename(can be wildcard), 
default is'*',i.e.match all 
-i NAME name of server instance(if using mysql.server startup script) 
-l don't subtract lock time from total time 








如 果 用 户 希 望 得 到 执行 时 间 最 长 的 10 条 SQL 语句 ， 可 以 运行 如 下 命 


4: 





[rootQnh119-141 data]#mysqldumpslow-s al-n 10 david.log 
Reading mysql slow query log from david.log 
Count:5 Time=0.00s(0s)Lock=0.20s(1s)Rows=4.4(22),Audition[Audition]@[192.168.30.108] 


SELECT OtherSN,State FROM wait friend info WHERE UserSN-N 
Count:1 Time=0.00s(0s)Lock=0.00s(0s)Rows=1.0(1),audition-kr[audition-kr]@[192.168.30.105] 
SELECT COUNT(N)FROM famverifycode WHERE UserSN=N AND verifycode='S' 





MySQL 5.1 开 始 可 以 将 慢 查 询 的 日 志 记 录放 入 一 张 表 中 ， 这 使 得 用 
户 的 查询 更 加 方便 和 直观 。 慢 查询 表 在 mysql 架 构 下 ， 名 为 slow_log， 其 
表 结 构 定义 如 下 : 





FM A | 


mysql1- SHOW CREATE TABLE ee. pare | log\G; 

FOI III III III IIIS RQ. oI III III III III II I Ik 
Table: slow_log 

Create Table:CREATE TABLE'slow_log'( 

'start time'timestamp NOT NULL DEFAULT CURRENT TIMESTAMP ON UPDATE CURRENT TIMESTAMP, 
'user host'mediumtext NOT NULL, 

'query time'time NOT NULL 

'lock time'time NOT NULL 

'rows sent'int(11)NOT NULL 

'rows examined'int(11)NOT NULL, 

'db'varchar(512)NOT NULL 

'last insert id'int(11)NOT NULL, 

'insert id'int(11)NOT NULL, 

'server id'int(11)NOT NULL 

'sql text'mediumtext NOT NULL 

)ENGINE=CSV DEFAULT CHARSET-utf8 COMMENT-'Slow log' 

1 row in set(0.00 sec) 





参数 log_output 指 定 了 慢 查 询 输 出 的 格式 ， 默 认为 FILE， 可 以 将 它 
设 为 TABLE， 然 后 就 可 以 查询 mysql 架 构 下 的 slow_log 表 了 ， 如 : 





mysql> SHOW VARTABLES LIKE' log. output '\G; 


1 row in set(0. 66 sec) 

mysql>SET GLOBAL log output-'TABLE'; 
Query OK,0 rows affected(0.00 sec) 
mysql> SHOW VARTABLES LIKE' ‘Jog output '\G; 


1 row in set(0. mH sec) 
VS select sleep(10)\G; 


1 row in set(10.01 sec) 
mysql>SELECT*FROM mysql.slow_log\G; 


start_time: 2009-09-25 13:44:29 
user_host:david[david]@localhost[] 
query_time:00:00:09 

lock_time: 00:00:00 

rows_sent:1 

rows_examined:0 

db:mysql 

last_insert_id:0 

insert_id:0 

server_id:0 

sql text:select sleep(10) 

1 row in set(0.00 sec) 





参数 log_output 是 动态 的 ， 并 且 是 全 局 的 ， 因 此 用 户 可 以 在 线 进行 
修改 。 在 上 表 中 人 为 设置 了 睡眠 (sleep) 10 秒 ， 那 么 这 名 SQL 语句 就 会 
被 记录 到 slow_log 表 了 。 


查看 slow_log 表 的 定义 会 及 现 该 表 使 用 的 是 CSV 引 擎 ， 对 大 数据 量 
下 的 查询 效率 可 能 不 高 。 用 户 可 以 把 slow_log 表 的 引擎 转换 到 
MyISAM， 并 在 start_time 列 上 添加 索引 以 进一步 提高 查询 的 效率 。 但 
是 ， 如 果 已 经 启动 了 慢 查 询 ， 将 会 提示 错误 : 

















mysql>ALTER TABLE mysql.s slou lo og ENBENES MyISM; 
ERROR 1580(HY000):You cannot'ALTER'a log table if logging is enabled 
mys ql>SET BESE slow_que e doro orf. 
ery ws affected(0.00 sec 
nys qf>ALTER TABLE T mysql.s slon log ENGINE=MyISAM; 
ae rs row are e d se i 
Sco rds Duplic ings, 








不 能 忽视 的 是 ， 将 slow_log 表 的 存储 引擎 更 改 为 MYISAM 后 ， 还 是 
会 对 数据 库 造 成 额外 的 开销 。 不 过 好 在 很 多 关于 慢 奋 询 的 参数 都 是 动态 
的 ， 用 户 可 以 方便 地 在 线 进行 设置 或 修改 。 


MySQL 的 slow ”log 通过 运行 时 间 来 对 SQL 语 句 进行 捕获 ， Did. 
非常 有 用 的 优化 技巧 。 但 是 当 数 据 库 的 容量 较 小 时 ， 可 能 
建立 ， 此 时 非常 大 的 可 能 是 数据 全 部 被 绥 存 在 缓冲 池 中 ，SQL 语 句 运 
的 时 间 可 能 都 是 非常 短 的 ， 一 般 都 是 0.5 秒 。 


InnoSQL 版 本 加 强 了 对 于 SQL 语 句 的 捕获 方式 。 在 原版 MySQL 的 基 
础 上 在 slow ”log 中 增加 了 对 于 逻辑 读 取 (logical reads) 和 物理 读 取 
(physical reads) 的 统计 。 这 里 的 物理 读 取 是 指 从 磁盘 进行 IO 读 取 的 次 
数 ， 轩 和 辑 读 取 包 含 所 有 的 读 取 ， 不 管 是 磁盘 还 是 缓冲 池 。 例 如 


























#Time:111227 23:49: 
#USer Si st:root[r oot Jalo galls Sieni 0.0.1] 
#Quer -ti me:6.081214 046800 Rows_sent:42 Rows_examined:727558 Logical_reads:91584 Physical_reads:19 
use th CC 
SET times sta ue imis qud 
SELECT orde sto rid,e employeeid, orderdate 
M ord 


WHERE orderdate 
(SELECT. maxar rder s te) 


M 
GROUP neve FORMAT(orderdate, '%Y%M' ) ) 
); 





从 上 面 的 例子 可 以 看 到 该 子 查 询 的 逻辑 读 取 次 数 是 91 584 次 ， 物 理 
读 取 为 19 次 。 从 逻辑 读 与 物理 读 的 比例 上 看 ， 该 SQL 语句 可 进行 优化 。 


用 户 可 以 通过 额外 的 参数 long_query_io 将 超过 指定 逻辑 IO 次 数 的 
SQL 语句 记录 到 slow log 中 。 该 值 默认 为 100， 即 表示 对 于 逻辑 读 取 次 数 
大 于 100 的 SQL 语句 ， 记 录 到 slow log 中 。 而 为 了 兼容 原 MySQL 数 据 库 的 
运行 方式 ， 还 添加 了 参数 slow_query_type， 用 来 表示 启用 slow log 的 方 
式 ， 可 选 值 为 : 


口 0 表 示 不 将 SQL 语句 记录 到 Slow log 
口 1 表示 根据 运行 时 间 将 SQL 语句 记录 到 Slow log 











D2 表示 根据 逻辑 IO 次 数 将 SQL 语 句 记 录 到 slow log 
口 3 表示 根据 运行 时 间 及 逻辑 IO 次 数 将 SQL 语句 记录 到 slow log 








3:33 Baas 


查询 日 志 记 录 了 所 有 对 MySQL 数 据 库 请 求 的 信息 ， 无 论 这 些 请 求 
or ne 默认 文件 名 为 : 主机 名 .log。 如 查看 一 个 查询 


"TUE 











[root@nineyou®-43 data]#tail nineyou0-43.1log 

090925 11:00:24 44 Connect z1m@192.168.0.100 on 

44 Query SET AUTOCOMMIT=0 

44 Query set autocommit=0 

44 Quit 

090925 11:02:37 45 Connect Access denied for user'root'Q'localhost'(using password:NO) 
090925 11:03:51 46 Connect Access denied for user'root'@'localhost'(using password:NO) 
090925 11:04:38 23 Query rollback 














过 上 述 查 询 日 志 会 发 现 ， 查询 日 志 甚至 记录 了 对 Access denied 的 
请 求 ， RODA 正确 执行 的 SQL 语句 ， 查 询 日 志 也 会 进行 记录 。 同 样 
地 ， 从 MySQL 5.1 开 始 ， 可 以 将 查询 日 志 的 记录 放 入 mysql 架 构 下 的 
general log 表 中 ， 该 表 的 使 用 方法 和 前 面 小 节 提 到 的 Slow_log 基 本 一 
Re, KER AAR. 











3.2.4 二进制 日 志 


二 进 制 日 志 (binary log) 记录 了 对 MySQL 数 据 库 执行 更 改 的 所 有 
操作 ， ee IE UM 因为 这 类 操作 对 数据 本 
身 并 没有 修改 。 然 而 ， 若 操作 本 身 并 没有 导致 数据 库 发 生变 化 ， 那 么 该 
操作 可 能 也 会 写 入 二 进 制 日 志 。 例 如 : 





mysql>UPDATE t SET a=1 WHERE a-2; 
Query OK,0 rows affected(0.00 sec) 
Rows matched: 0 Changed:0 Warnings:0 
mysql1- SHOW MASTER STATUS\G; 


File:mysqld.000008 

Position:383 

Binlog_Do_DB: 

Binlog_Ignore_DB: 

Executed_Gtid_Set: 

1 row in set(0.00 sec) 

mysql- SHOW BINLOG EVENTS IN'mysqld.000008'^6G; 
JOOOOEOOOOOOOROOOGOOOOOOOOOOOR] I E ERCOOOODOOOOOORHOOOIOOOOORROROR 
Log i nang: mysqld .000008 

Pos: 

E .type:Format desc 

Server id:1 

End log pos:120 

Info:Server ver:5.6.6-m9-1log, prb ver:4 

FOI II II III III II ROGER S pup GI II III IGG I 
Log. nane: mysqld .000008 

Pos:120 

Event . type:Query 

Server id:1 

End log pos:199 

Info:BEGIN 


Log name:mysqld.000098 

Pos:199 

Event type:Query 

Server id:1 

End log pos:303 

Info:use'test';UPDATE t SET a-1 WHERE a-2 
ROGER ROGO OG OR OR ORAL pp REKKE KKE KKE KKE KARK KRKE K K 
Log i S mysqld .000008 

Pos:303 

Bae . type:Query 

Server id:1 

End log pos:383 

Info:COMMIT 

4 rows in set(0.00 sec) 





从 上 述 例子 中 可 以 看 到 ，MySQL 数 据 库 首 先进 行 UPDATE 操 作 ， 
从 返回 的 结果 看 到 Changed 为 0， 这 意味 着 该 操作 并 没有 导致 数据 库 的 变 
化 。 但 是 通过 命令 SHOW BINLOG EVENT 可 以 看 出 在 二 进 制 日 志 中 的 
确 进行 了 记录 。 


如 果 用 户 想 记录 SELECT 和 SHOW 操作 ， 那 只 能 使 用 查询 日 志 ， 
不 是 二 进 制 日 志 。 此 外 ， 二 进 制 日 志 还 包括 了 E RR DOR ACRI 
间 等 其 他 额外 信息 。 总 的 来 说 ， 二 进 制 日 志 主 要 有 以 下 几 种 作用 。 


OWE (recovery) : 某 些 数据 的 恢 进 制 日 志 ， 例 如 ， 在 
一 个 数据 库 全 备 文件 恢复 后 ， 用 户 可 以 通过 二 进 制 日 志 进行 point-in- 








time 的 恢复 。 


口 复 制 replication) : 其 原理 与 恢复 类 似 ， 通 过 复制 和 执行 二 进 
制 日 志 使 一 台 远程 的 MySQL 数 据 库 一般 称 为 slave 或 standby) 与 一 台 
MySQL SHE lc (一 般 称 为 master 或 primary) 进行 实时 同步 。 


口 审 计 Caudit) : 用 户 可 以 通过 二 进 制 日 志 中 的 信息 来 进行 审计 ， 
判断 是 否 有 对 数据 库 进行 注入 的 攻击 。 


通过 配置 参数 log-bin[=name] 可 以 启动 二 进 制 日 志 。 如 果 不 指定 
name， 则 默认 二 进 制 日 志文 件 名 为 主机 名 ， 后 级 名 为 二 进 制 日 志 的 序列 
写 ， 所 在 路 径 为 数据 库 所 在 目录 (datadir) ， 如 : 














+---------------+----------------------------+ 
+---------------+----------------------------+ 
+---------------+----------------------------+ 


set(0 ec) 
d Roles ys ste is Shy sr/local/mysql/data/; 
to ota E 2. 


nys ql 256M Sep 25 15:13 ib logfi 
ysql 256M Se ep 25 15:13 ib- logfi 


EE ag 


Ai ita 
22223232 
= = 





这 里 的 bin_log.00001 即 为 二 进 制 日 志文 件 ， 我 们 在 配置 文件 中 指定 
了 名 字 ， 所 以 没有 用 默认 的 文件 名 。bin p e 
件 ， 用 来 存储 过 往 产 生 的 三 进 制 日 志 序 号 ， 在 通常 情况 下 ， 不 建议 手工 
修改 这 个 文件 。 


二 进 制 日 志文 件 在 默认 情况 下 并 没有 局 动 ， 需 要 手动 指定 参数 来 局 
动 。 可 能 有 人 会 质疑 ， 开 局 这 个 选项 是 否 会 对 数据 库 整 体 性 能 有 所 影 
啊 。 不 错 ， 开 局 这 个 选项 的 确 会 影响 性 能 ， 但 是 性 能 的 损失 十 分 有 限 。 
根据 MySQL 定 方 手册 中 的 测试 表明 ， 开 局 二 进 制 日 志 会 使 性 能 下 降 
19%。 但 考虑 到 可 以 使 用 复制 (replication) 和 point-in-time 的 恢复 ， 这 些 
性 能 损失 绝对 是 可 以 且 应 该 被 接受 的 。 


以 下 配置 文件 的 参数 影响 着 二 进 制 日 志 记录 的 信息 和 行为 : 








Llmax binlog size 


Llbinlog cache size 


Llsync binlog 
Llbinlog-do-db 

La binlog-ignore-db 
Lllog-slave-update 
Llbinlog format 


参数 max_binlog_size 指 定 了 单个 二 进 制 日 志文 件 的 最 大 值 ， 如 果 超 
过 该 值 ， 则 产生 新 的 三 进 制 日 志文 件 ， 后 级 名 +1， 并 记录 到 .index 文 
件 。 从 MySQL 5.0 开 始 的 默认 值 为 1 073 741 824， 代 表 1 G (在 之 前 版 本 
中 max_binlog_size 默 认 大 小 为 1.1G) o 


当 使 用 事务 的 表 存 储 引 擎 〈 如 InnoDB 存 储 引擎 ) 时 ， 所 有 未 提交 

Cuncommitted) 的 二 进 制 日 志 会 被 记录 到 一 个 缓存 中 去 ， 等 该 事务 提 
交 (committed) 时 直接 将 缓冲 中 的 二 进 制 日 志 写 入 二 进 制 日 志文 件 ， 
而 该 绥 冲 的 大 小 由 binlog_cache_size 决 定 ， 默 认 大 小 为 32K。 此 外 ， 
binlog. cache sizexéJ& T 21 (session) 的 ， 也 就 是 说 ， 当 一 个 线程 开 
始 一 个 事务 时 ，MySQL 会 自动 分 配 一 个 大 小 为 binlog_cache_size 的 绥 
存 ， 因 此 该 值 的 设置 需要 相当 小 心 ， 不 能 设置 过 大 。 当 一 个 事务 的 记录 
大 于 设 定 的 binlog_cache_size 时 ，MySQL 会 把 缓冲 中 的 日 志 写 入 一 个 临 
时 文件 中 ， 因 此 该 值 又 不 能 设 得 太 小 。 通 过 SHOW GLOBAL STATUS 
命令 查看 binlog_cache_use、binlog_cache_disk_use 的 状态 ， 可 以 判断 当 
前 binlog_cache_size 的 设置 是 否 合适 。Binlog_cache_use 记 录 了 使 用 缓冲 
写 二 进 制 日 志 的 次 数 ，binlog_cache_disk_use 记 录 了 使 用 临时 文件 写 二 
进 制 日 志 的 次 数 。 现 在 来 看 一 个 数据 库 的 状态 : 








mysql>show variables like'binlog cache size'; 


Rhbuolnexeh Med ddeqoleinecE 


和 


A pe test 
1 row in set(0.00 sec) 
mysql>show global status like'binlog cache*'; 


OP E 


PA Om RA cee Sees ocee oh 
|binlog cache disk use|0| 
|binlog cache use|33553| 

Pacers et cece Ste Cet pete oe ei + 


2 rows in set(@.00 sec) 





使 用 缓冲 次 数 为 33 553， 临 时 文件 使 用 次 数 为 0。 看 来 32KB 的 缓冲 


大 小 对 于 当前 这 个 MySQL 数 据 库 完 全 够 用 ， 和 暂时 没有 必要 增加 
binlog_cache_size 的 值 。 


在 默认 情况 下 ， 二 进 制 日 志 并 不 是 在 每 次 写 的 时 候 同 步 到 磁盘 (用 
户 可 以 理解 为 缓冲 写 ) 。 因 此 ， 当 数据 库 所 在 操作 系统 发 生 宕 机 时 ， 可 
能 会 有 最 后 一 部 分 数据 没有 写 入 二 进 制 日 志文 件 中 ， 这 会 给 恢复 和 复制 
带 来 问题 。 参 数 sync_binlog=[N] 表 示 每 写 缓冲 多 少 次 就 同步 到 磁盘 。 如 
果 将 N 设 为 1， 即 sync_binlog=1 表 示 采 用 同步 写 磁盘 的 方式 来 写 二 进 制 日 
志 ， 这 时 写 操作 不 使 用 操作 系统 的 缓冲 来 写 二 进 制 日 志 。sync_binlog 的 
默认 值 为 0， 如 果 使 用 InnoDB 存 储 引 擎 进行 复制 ， 并 且 想 得 到 最 大 的 高 
可 用 性 ， 建 议 将 该 值 设 为 ON。 不 过 该 值 为 ON 时 ， 确 实 会 对 数据 库 的 IO 
系统 带 来 一 定 的 影响 。 


但 是 ， 即 使 将 sync_binlog 设 为 1， 还 是 会 有 一 种 情况 导致 问题 的 发 
生 。 当 使 用 mnoDB 存 储 引 警 时 ， 在 一 个 事务 发 出 COMMIT 动 作 之 前 ， 
由 于 sync_binlog 为 1， 因 此 会 将 二 进 制 日 志 立 即 写 入 磁盘 。 如 果 这 时 已 
经 写 入 了 二 进 制 日 志 ， 但 是 提交 还 没有 发 生 ， 并 且 此 时 发 生 了 宕 机 ， 那 
么 在 MySQL 数 据 库 下 次 启动 时 ， 由 于 COMMIT 操 作 并 没有 发 生 ， 这 个 
事务 会 被 回 滚 掉 。 但 是 二 进 制 日 志 已 经 记录 了 该 事务 信息 ， 不 能 被 回 
深 。 这 个 问题 可 以 通过 将 参数 innodb_support_xa 设 为 1 来 解决 ， 虽 然 
innodb_support_xa 与 XA 事务 有 关 ， 但 它 同 时 也 确保 了 二 进 制 日 志和 
InnoDB 存 储 引 擎 数据 文件 的 同步 。 


参数 binlog-do-db 和 binlog-ignore-db 表 示 需 要 写 入 或 忽略 写 入 哪些 库 
的 日 志 。 默 认为 空 ， 表 示 需 要 同步 所 有 库 的 日 志 到 二 进 制 日 志 。 


如 果 当 前 数据 库 是 复制 中 的 slave 角 色 ， 则 它 不 会 将 从 master 取 得 并 
执行 的 二 进 制 日 志 写 入 自己 的 二 进 制 日 志文 件 中 去 。 如 果 需 要 写 入 ， 要 
设置 1og-slave-update。 如 果 需 要 搭建 master= 之 slave= 之 slave 架 构 的 复 
制 ， 则 必须 设置 该 参数 。 


binlog_format 参 数 十 分 重要 ， 它 影响 了 记录 二 进 制 日 志 的 格式 。 在 
MySQL 5.1 版 本 之 前 ， 没 有 这 个 参数 。 所 有 二 进 制 文件 的 格式 都 是 基于 
SQL 语 句 (statement) 级 别 的， 因此 基于 这 个 格式 的 二 进 制 日 志文 件 的 
复制 〈Replication) 和 Oracle 的 逻辑 Standby 有 点 相似 。 同 时 ， 对 于 复制 
是 有 一 定 要 求 的 。 如 在 主 服 务 器 运行 rand、uuid 等 图 数 ， 又 或 者 使 用 触 
发 需 等 操作 ， 这 些 都 可 能 会 导致 主 从 服务 器 上 表 中 数据 的 不 一 致 (not 
sync) 。 男 一 个 影响 是 ， 会 发 现 ImhnoDB 存 储 引 擎 的 默认 事务 隔离 级 别 是 


















































REPEATABLE READ。 这 其 实 也 是 因为 二 进 制 日 志文 件 格式 的 关系 ， 
如 果 使 用 READ COMMITTED 的 事务 隔离 级 别 〈 大 多 数 数据 库 ， 如 
Oracle, Microsoft SQL Server 数 据 库 的 默认 隔离 级 别 ) ， 会 出 现 类 似 丢 
失 更 新 的 现象 ， 从 而 出 现 主 从 数据 库 上 的 数据 不 一 致 。 


MySQL 5.1 开 始 引 入 了 binlog_format 参 数 ， 该 参数 可 设 的 值 有 
STATEMENT、ROW 和 MIXED。 


(1) STATEMENT 格 式 和 之 前 的 MySQL 版 本 一 样 ， 二 进 制 日 志文 
件 记录 的 是 日 志 的 轴 辑 SQL 语句 。 


(2) 在 ROW 格式 下 ， 二 进 制 日 志 记录 的 不 再 是 简单 的 SQL 语句 
了 ， 而 是 记录 表 的 行 更 改 情 况 。 基 于 ROW 格式 的 复制 类 似 于 Oracle 的 物 
理 Standby《〈 当 然 ， 还 是 有 些 区 别 ) 。 同 时 ， 对 上 述 提 及 的 Statement 格 
式 下 复制 的 问题 予以 解决 。 从 MySQL 5.1 版 本 开始 ， 如 果 设 置 了 
binlog_format 为 ROW， 可 以 将 ImnoDB 的 事务 隅 离 基本 设 为 READ 
COMMITTED， 以 获得 更 好 的 并 发 性 。 


(3) 在 MIXED 格 式 下 ，MySQL 默 认 采 用 STATEMENT 格 式 进 行 二 
日 志文 件 的 记录 ， 但 是 在 一 些 情况 下 会 使 用 ROW 格式 ， 可 能 的 情 
况 有 : 


D 表 的 存储 引擎 为 NDB， 这 时 对 表 的 DML 操 作 都 会 以 ROW 格式 记 
录 。 














2) 使 用 了 UUIDO、USERO、CURRENT_USERO、 
FOUND_ROWSO、ROW_COUNTO0 等 不 确定 函数 。 


3) 使 用 了 INSERT DELAY 语 句 。 

4) 使 用 了 用 户 定义 函数 (UDF) 。 

5) 使 用 了 临时 表 (temporary table) . 

此 外 ，binlog_format 参 数 还 有 对 于 存储 引擎 的 限制 ， 如 表 3-1 所 示 。 





i 


At 


KREAS AARRE 


Alle Seltenes 
InnoDB Yes 
MyISAM Yes Yes 
HEAP Yes Yes 
MERGE " 
NDB Yes N 
Archiv Yes Yes 
MI Yes 
Federate Yes Yes 
Blackhole Yes 


binlog_format 是 动态 参数 ， 因 此 可 以 在 数据 库 运 行 环境 下 进行 更 
改 ， 例 如 ， 我 们 可 以 将 当前 会 话 的 binlog_format 设 为 ROW， 如 : 


下 
中 


证 





当然 ， 也 可 以 将 全 局 的 binlog format 设 置 为 想 要 的 格式 ， 不 过 通常 
这 个 操作 会 带 来 问题 ， 运 行 时 要 确保 更 改 后 不 会 对 复制 带 来 影响 。 如 : 








mysql>SET GLOBAL binlog format-'ROW'; 
Query OK,0 rows affected(0.00 sec) 
Tysql--SELECTQOglobal. binlog_ format; 


1 row in set(0.00 sec) 





在 通常 情况 下 ， binlog formari T AROW 这 可 以 为 数 
据 库 的 恢复 和 复制 带 来 更 好 的 可 靠 性 。 但 是 不 能 忽略 的 一 点 是 ， 这 会 带 
来 二 进 制 文件 大 小 的 增加 ， 有 些 语句 下 的 ROW 格式 可 能 需要 更 大 的 容 
量 。 比 如 我 们 有 两 张 一 样 的 表 ， 大 小 都 为 100W， 分 别 执行 UPDATE 操 
作 ， 观 察 二 进 制 日 志 大 小 的 变化 : 








mysql>SELECT@@session.binlog_ mined 

FOI IIIT IIIT e pp FE FE Fe E IIIT III A 
@@session. ee a cds STATEMENT 

1 row in set(0.0 ec) 

mysq1- SHOW MASTER STATUS\G; 


File:test.000003 

Position:106 

Binlog Do DB: 

Binlog Ignore DB: 

1 row in set(0.00 sec) 

mysql>UPDATE t1 SET username=UPPER(username) ; 
Query OK,89279 rows affected(1.83 sec 

Rows matched:100000 Changed:89279 Warnings:0 
mysql>SHOW MASTER STATUS\G; 


Binlog_Ignore_DB: 
1 row in set(0.00 sec) 





可 以 看 到 ， 在 binlog_format 格 式 为 STATEMENT 的 情况 下 ， 执 行 
UPDATE 语 句 后 二 进 制 日 志 大 小 只 增加 了 200 字 节 (306-1060 。 如 果 使 
用 ROW 格式 ， 同 样 对 (2 表 进 行 操 作 ， 可 以 看 到 ; 





mysql>SET SESSION binlog format-'ROW'; 
Query OK,0 rows affected(0.00 sec) 
mysq1- SHOW MASTER STATUS\G; 


File:test.000003 

Position:306 

Binlog Do DB: 

Binlog Ignore DB: 

1 row in set(0.00 sec 

mysql>UPDATE t2 SET username=UPPER(username) ; 
Query OK,89279 rows affected(2.42 sec 

Rows matched:100000 Changed:89279 Warnings:0 
mysql>SHOW MASTER STATUS\G; 


File: test .000003 
Position:13782400 
Binlog_Do_DB: 

Binlog_Ignore_DB: 


1 row in set(0.00 sec) 





这 时 会 惊讶 地 发 现 ， 同 样 的 操作 在 ROW 格式 下 竟然 需要 13 782 094 
字 节 ， 二 进 制 日 志文 件 的 大 小 差不多 增加 了 13MB， 要 知道 t2 表 的 大 小 
也 不 超过 17MB。 而 且 执行 时 间 也 有 所 增加 《〈 这 里 我 设置 了 
sync_binlog=1) 。 这 是 因为 这 时 MySQL 数 据 库 不 再 将 逻辑 的 SQL 操作 记 
录 到 二 进 制 日 志 中 ， 而 是 记录 对 于 每 行 的 更 改 。 


上 面 的 这 个 例子 告诉 我 们 ， 将 参数 binlog_format 设 置 为 ROW， 会 对 
磁盘 空间 要 求 有 一 定 的 增加 。 而 由 于 复制 是 采用 传输 二 进 制 日 志方 式 实 
现 的 ， 因 此 复制 的 网 络 开销 也 有 所 增加 。 


二 进 制 日 志文 件 的 文件 格式 为 二 进 制 (好像 有 点 上 废话) ， 不 能 像 错 
误 日 志文 件 、 慢 查询 日 志文 件 那 样 用 cat、head、 tail 等 命令 来 查看 。 要 
查看 二 进 制 日 志文 件 的 内 容 ， 必 须 通 过 MySQL 提 供 的 工具 
mysqlbinlog. 对 于 STATEMENT 格 式 的 二 进 制 日 志文 件 ， 在 使 用 
mysqlbinlog 后 ， 看 到 的 就 是 执行 的 逻辑 SQL 语句 ， 如 : 























[rogtanineyous- 43 data]#mysqlbinlog--start- er 203 test .000004 
/*140019 SET@@session.max_insert_delayed_threads=0* 


#090927 15:43:11 server oe 1 end_log_pos 376 Query thread_id=188 exec_time=1 error_code=0 
SET TIMESTAMP-1254037391/*!*/; 

update t2 set username= 人 id=1 

VEA 


#at 376 

#090927 15; 43:11 server id 1 end log pos 403 Xid-1009 
COMMIT/*!*/; 

让 

#End of log file 

ROLLBACK/*added by mysqlbinlog*/; 

/*150003 SET COMPLETION TYPE-I QOLD | COMPLETION TYPE*/; 





通过 SQL 语 名 UPDATE t2 SET  username-UPPER (username) 
WHERE id=1 可 以 看 到 ， 二 进 制 日 志 的 记录 采用 SQL 语句 的 方式 CON 
排版 的 方便 ， 省 去 了 一 些 开 始 的 信息 ) 。 在 这 种 情况 下 ，mysqlbinlog 和 
Oracle ”LogMiner 类 似 。 但 是 如 果 这 时 使 用 ROW 格式 的 记录 方式 ， 会 发 
现 mysqlbinlog 的 结果 变 得 “不 可 读 ”(unreadable) , ZU: 








[rootgnineyouó- 43 data]#mysqlbinlog--start- EREA 1065 test . 000004 
/*140019 SET@@session.max_insert_delayed_threads=0* 


Hat 1135 

#at 1198 

#090927 15:53:52 server id 1 end log pos 1198 Table map: 'member'.'t2'mapped to number 58 
#090927 15:53:52 server id 1 end log pos 1378 Update rows:table id 58 flags:STMT END F 
BINLOG' 

EBq/ShMBAAAAPWwAAAKAEAAAAADOAAAAAAAAABm1 1bWJ 1cgACdDIACgMPDw/-Cg sSPAQwWKJAAOAEAA 

/gJAAAAA 

EBq/ShgBAAAAtAAAAGIFAAAQADOAAAAAAAEACV / / / /BA/ AEAAAALYWXleDK50Dh5b3UEOX1vdSA3 
Y2JiMzI1MmJhNmI3ZTljNDIyZmFjNTMzNGQyMj A1NAFNLacPAAAAAAB;j EnpxPBIAAADBAQAAAAtB 
TEVYOTkAOF1PVQQ5eW91IDdjYmIzMjUyYmE2Y.;dlOWMOM;j JmYWM1MzMOZDIyMDUOAUOt pw8AAAAA 
AGMSenE8EgAA 

iy aad a A 


#at 1378 

#090927 15:53:52 server id 1 end log pos 1405 Xid-1110 
COMMIT/*!*/; 

DELIMITER; 

4End of log file 

ROLLBACK/*added by mysqlbinlog*/; 

/*150003 SET COMPLETION TYPE-QOLD COMPLETION TYPE*/; 





这 里 看 不 到 执行 的 SQL 语句 ， 反 而 是 一 大 串 用 户 不 可 读 的 字符 。 其 
实 只 要 加 上 参数 -v 或 -vv 就 能 清楚 地 看 到 执行 的 具体 信息 了 。-vv 会 比 -v 
多 显示 出 更 新 的 类 型 。 加 上 -vv 选项 ， 可 以 得 到 : 





[rootQünineyouO-43 data]#mysqlbinlog-vv--start-position=1065 test.000004 


BINLOG' 
EBq/ShMBAAAAPWAAAK4EAAAAADOAAAAAAAAABM1 1bWJ 1c gACdDIACgMPDw/-Cg SPAQWK JAAOAEAA 
/gJAAAAA 
EBq/ShgBAAAAtAAAAGIFAAAQADOAAAAAAAEACV / / / /8BA/ AEAAAALYWXleDK50Dh5b3UEOX1vdSA3 
Y2JiMzI1MmJhNmI3ZTljNDIyZmF;jNTMzNGQyMj A1NAFNLacPAAAAAAB;j EnpxPBIAAADBAQAAAAtB 
TEVYOTkAOF1PVQQ5eW91IDdjYmIzMjUyYmE2Y;jdlOWMOM;j JmYWM1MzMOZDIyMDUOAUOt pw8AAAAA 
AGMSenE8EgAA 

ty el eel ae 

:HHEUPDATE member. t2 

###WHERE 

###@1=1/*INT meta=0 nullable=0 is null-0*/ 
###@2='david'/*VARSTRING(36)meta=36 nullable=0 is null-0*/ 
###@3='family'/*VARSTRING(40)meta=40 nullable=0 is null-0*/ 

###@4=' 7cbb3252ba6b7e9c422fac5334d22054' /* VARSTRING(64)meta-64 nullable=0 is null-0*/ 
###@5='M'/*STRING(2)meta=65026 nullable=0 is null-0*/ 
###@6='2009:09:13'/*DATE meta=0 nullable=0 is null-0*/ 
###@7='00:00:00'/*TIME meta-O nullable=0 is null-0*/ 
###@8=''/*VARSTRING(64)meta=64 nullable=0 is null-0*/ 

###@9=0/*TINYINT meta=0 nullable=0 is null-0*/ 

###@10=2009-08-11 16:32:35/*DATETIME meta=0 nullable=0 is null-0*/ 

THHESET 

###@1=1/* INT meta=0 nullable=0 is null-0*/ 
###@2='DAVID'/*VARSTRING(36)meta=36 nullable=0 is null-0*/ 
###@3=family/*VARSTRING(40)meta=40 nullable=0 is null-0*/ 

###@4=' 7cbb3252ba6b7e9c422fac5334d22054' /* VARSTRING(64)meta-64 nullable=0 is null-0*/ 
###@5='M'/*STRING(2)meta=65026 nullable=0 is null-0*/ 
###@6='2009:09:13'/*DATE meta=0 nullable=0 is null-0*/ 
##H#@7='00:00:00'/*TIME meta-O nullable=0 is null-0*/ 
###@8=''/*VARSTRING(64)meta=64 nullable=0 is null-0*/ 

###@9=0/*TINYINT meta=0 nullable=0 is null-0*/ 

###@10=2009-08-11 16:32:35/*DATETIME meta=0 nullable=0 is null-0*/ 

#at 1378 

#090927 15:53:52 server id 1 end log pos 1405 Xid-1110 

COMMIT/*!*/; 

DELIMITER; 

4End of log file 

ROLLBACK/*added by mysqlbinlog*/; 

/*150003 SET COMPLETION TYPE-QOLD COMPLETION TYPE*/; 





现在 mysqlbinlog 回 我 们 解释 了 它 具 体 做 的 事情 。 可 以 看 到 ， 一 句 简 
单 的 update t2 set username-upper(username)where id=1 语 名 记录 了 对 于 整 
个 行 更 改 的 信息 ， 这 也 解释 了 为 什么 前 面 更 新 了 10W 行 的 数据 ， 在 
ROW 格式 下 ， 二 进 制 日 志文 件 会 增 大 13MB。 





20 SEP XT 


前 面 提 到 过 ， 在 UNIX 系 统 下 本 地 连接 MySQL 可 以 采用 UNIX 域 套 
接 字 方 式 ， 这 种 方式 需要 一 个 套 接 字 (socket) 文件 。 套 接 字 文件 可 由 
参数 socket 控 制 。 一 般 在 /Htmp 目 录 下 ， 名 为 mysql.sock: 














mysql>SHOW VARIABLES LIKE'socket'\G; 
JOOOOOIOOIOOOOOOOOOOOOOOOOOOR] 6 QF IEC III I ICI GI II I Ie 
Variable name:socket 

Value:/tmp/mysql.sock 

1 row in set(0.00 sec) 





3.4 pid 文件 


当 MySQL 实 例 启动 时 ， 会 将 自己 的 进程 ID 写 入 一 个 文件 中 一 一 该 
文件 即 为 pid 文 件 。 该 文件 可 由 参数 pid_file 控 制 ， 默 认 位 于 数据 库 目 录 
下 ， 文 件 名 为 主机 名 .pid: 











mysql>show variables like'pid_file'\G; 
JOOOOOOOIOOOOOOOOOOIOOOOROOOOOR LI pj FI GCISII III ICICI III IIIA I I Ie 
Variable_name:pid_file 

Value: /usr/local/mysql/data/xen-server .pid 

1 row in set(0.00 sec) 








3.5 AME MME 


因为 MySQL 插 件 式 存储 引擎 的 体系 结构 的 关系 ，MySQL 数 据 的 存 
储 是 根据 表 进 行 的 ， 每 个 表 都 会 有 与 之 对 应 的 文件 。 但 不 论 表 采 用 何 种 
存储 引擎 ，MySQL 都 有 一 个 以 frm 为 后 级 名 的 文件 ， 这 个 文件 记录 了 该 
表 的 表 结 构 定义 。 


frm 还 用 来 存放 视图 的 定义 ， 如 用 户 创建 了 一 个 v_a 视 图 ， 那 么 对 应 
地 会 产生 一 个 v_a.frm 文 件 ， 用 来 记录 视图 的 定义 ， 该 文件 是 文本 文件 ， 
可 以 直接 使 用 cat 命 令 进行 查看 : 














[root@xen-server test]écat v a.frm 

TYPE=VIEW 
query=select'test'.'a'.'b'AS'b'from'test'.'a' 
md5-4eda70387716a4d6c96f3042dd68b742 
updatable=1 

algorithm=0 

definer_user=root 

definer_host=localhost 

suid=2 

with_check_option=0 

timestamp=2010-08-04 07:23:36 
create-version=1 

source=select*from a 

client_cs_name=utf8 
connection_cl_name=utf8_general_ci 
view_body_utf8=select'test'.'a'.'b'AS'b'from'test'.'a' 


aT: | 


3.6 ”InnoDB 存 储 引 擎 文件 


之 前 介绍 的 文件 都 是 MySQL 数 据 库 本 身 的 文件 ， 和 存储 引擎 无 
关 。 除 了 这 些 文件 外 ， 每 个 表 存 储 引 擎 还 有 其 目 己 独 有 的 文件 。 本 节 将 
具体 介绍 与 nnoDB 存 储 引擎 密切 相关 的 文件 ， 这 些 文 件 包括 重 做 日 志 
文件 、 表 空间 文件 。 


3.6.1. REP 


InnoDB 采 用 将 存储 的 数据 按 表 空间 (tablespace) 进行 存放 的 设 
计 。 在 默认 配置 下 会 有 一 个 初始 大 小 为 1IMB， 名 为 ibdatal 的 文件 。 议 
文件 就 是 默认 的 表 空 间 文 件 (tablespace file) ， 用 户 可 以 通过 参数 
innodb data file path 对 其 进行 设置 ， 格 式 如 下 : 














innodb data file path-datafle speci[;datafle spec2]... 





i Hi ur EDS PS SCE 7 AREN, E il ECE E, 
Hs 





[mysqld] 
innodb data file path-/db/ibdata1:2000M;/dr2/db/ibdata2:2000M:autoextend 





这 里 将 /dbyibdata1 和 /dr2/dbyibdata2 两 个 文件 用 来 组 成 表 空 间 。 若 这 
两 个 文件 位 于 不 同 的 磁盘 上 ， 磁 盘 的 负载 可 能 被 平均 ， 因 此 可 以 提高 数 
据 库 的 整体 性 能 。 同 时 ， 两 个 文件 的 文件 名 后 都 跟 了 属性 ， 表 示 文 件 
idbdatal 的 大 小 为 2000MB， 文 件 ibdata2 的 大 小 为 2000MB， 如 果 用 完了 
这 2000MB， 访 文件 可 以 自动 增长 (autoextend) 。 


设置 innodb_data_file path 参数 后 ， 所 有 基于 InnoDB 存 储 引擎 的 表 
的 数据 都 会 记录 到 该 共享 表 空 间 中 。 奎 设置 了 参数 
innodb_file_per_ table， 则 用 户 可 以 将 每 个 基于 InnoDB 存 储 引 擎 的 表 产 生 
一 个 独立 表 空 间 。 独 立 表 空间 的 命名 规则 为 : 表 名 .ibd。 通 过 这 样 的 方 
式 ， 用 户 不 用 将 所 有 数据 都 存放 于 默认 的 表 空 间 中 。 下 面 这 台 MySQL 
数据 库 服 务 器 设置 了 innodb_file_per_table， 故 可 以 观察 到 : 





mysql>SHOW VARIABLES LIKE'innodb file per table'*6; 
ORO ORIGO IO IO GIORGIOR GIO ROR OR] (QW TORO EO OE OO OE OG KRKE KKK 


Variable name:innodb file per table 

Value:ON 

1 row in set(0.00 sec) 

mysql>system ls-lh/usr/local/mysql/data/member/* 

- r-----1 mysql mysql 8.7K 2009-92-24/usr/local/mysql/data/member/Profile.frm 
-rw-r-----1 mysql mysql 1.7G 9 月 25 11:13/usr/local/mysql/data/member/Profile.ibd 
-rw-rw----1 mysql mysql 8.7K 9 月 27 13:38/usr/local/mysql/data/member/t1i.frm 
-rw-rw----1 mysql mysql 17M 9 月 27 13:40/usr/local/mysql/data/member/ti.ibd 
-rw-rw----1 mysql mysql 8.7K 9 月 27 15:42/usr/local/mysql/data/member/t2. frm 
-rw-rw----1 mysql mysql 17M 9 月 27 15:54/usr/local/mysql/data/member/t2.ibd 





表 Profile、t1 和 t2 都 是 基于 InnoDB 存 储 的 表 ， 由 于 设置 参数 
innodb file per table=ON， 因 此 产生 了 单独 的 .ibd 独 立 表 空间 文件 。 需 
要 注意 的 是 ， 这 些 单 独 的 表 空 间 文件 仅 存 储 该 表 的 数据 、 过 引 和 插入 绥 
冲 BITMAP 等 信息 ， 其 余 信息 还 是 存放 在 默认 的 表 空 间 中 。 图 3-1 显 示 了 
InnoDB 存 储 引 擎 对 于 文件 的 存储 方式 : 








InnoDB 


share 


tablespace 











图 3-1 InnoDB 表 存储 引擎 文件 


3.6.2” 重 做 日 志文 件 


在 默认 情况 下 ， 在 InnoDB 存 储 引 擎 的 数据 目录 下 会 有 两 个 名 为 
ib_logfile0 和 ib_logfile1 的 文件 。 在 MySQL 官 方 手册 中 将 其 称 为 mnnoDB 
存储 引擎 的 日 志文 件 ， 不 过 更 准确 的 定义 应 该 是 重 做 日 志文 件 Credo 
log file) 。 为 什么 强调 是 重 做 日 志文 件 呢 ? 因为 重 做 日 志文 件 对 于 
InnoDB ff i5 擎 至 关 重 要 ， 它 们 记录 了 对 于 InnoDB 存 储 引 警 的 事务 日 


Ur 














当 实 例 或 介质 失败 (media failure) 时 ， 重 做 日 志文 件 就 能 派 上 用 
场 。 例 如 ， 数 据 库 由 于 所 在 主机 掉 电 导致 实例 失败 ，InnoDB 存 储 引 擎 
会 使 用 重 做 日 志 恢 复 到 掉 电 前 的 时 刻 ， 以 此 来 保证 数据 的 完整 性 。 


每 个 mnoDB 存 储 引 擎 至 少 有 1 个 重 做 日 志文 件 组 〈group) ， 每 个 文 
件 组 下 至 少 有 2 个 重 做 日 志文 件 ， 如 默认 的 ib_logfile0 和 ib_logfile1。 为 
了 得 到 更 高 的 可 靠 性 ， 用 户 可 以 设置 多 个 的 镜像 日 志 组 (mirrored log 
groups) ， 将 不 同 的 文件 组 放 在 不 同 的 磁盘 上 ， 以 此 提高 重 做 日 志 的 高 
可 用 性 。 在 日 志 组 中 每 个 重 做 日 志文 件 的 大 小 一 致 ， 并 以 循环 写 入 的 方 
式 运 行 。InnoDB 存 储 引擎 先 写 重 做 日 志文 件 1， 当 达到 文件 的 最 后 时 ， 
会 切换 至 重 做 日 志文 件 2， 再 当 重 做 日 志文 件 2 也 被 写 满 时 ， 会 再 切换 到 
25 志文 件 1 中 。 图 3-2 显 示 了 一 个 拥有 3 个 重 做 日 志文 件 的 重 做 日 志 
文件 组 。 
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图 3-2 日 志文 件 组 
下 列 参 数 影 响 着 重 做 日 志文 件 的 属性 : 
Uinnodb log file size 
Llinnodb log files in. group 
Llinnodb mirrored log groups 
Llinnodb log group home dir 


参数 innodb log file_size 指 定 每 个 重 做 日 志文 件 的 大 小 。 在 
InnoDB1.2.x 版 本 之 前 ， 重 做 日 志文 件 总 的 大 小 不 得 大 于 等 于 4GB， 而 








1.2.x 版 本 将 该 限制 扩大 为 了 512GB。 


参数 innodb log files_in_group 指 定 了 日 志文 件 组 中 重 做 日 志文 件 的 
数量 ， 默 认为 2。 参 数 innodb_mirrored_log_groups 指 定 了 日 志 镜 像 文件 
组 的 数量 ， 默 认为 1， 表 示 只 有 一 个 日 志文 件 组 ， 没 有 镜像 。 若 磁盘 本 
里 已 经 做 了 高 可 用 的 方案 ， 如 磁盘 阵列 ， 那 么 可 以 不 开启 重 做 日 志 镜 像 
的 功能 。 最 后 ， 参 数 innodb_ log group_home dir 指定 了 日 志文 件 组 所 在 
路 径 ， 默 认为 .,， 表 示 在 MySQL 数 据 库 的 数据 目录 下 。 以 下 显示 了 一 个 
关于 重 做 日 志 组 的 配置 : 











mysql>SHOW VARIABLES LIKE' Feuer et NG Fe 

FOI III ISIE], p RO Rok koe elo III I KKK 
Variable_name: innodb_log_ file. size 

Value: 5242880 


ORI KK IO IK TOK IK IK OK IK RR p gy RR RRR RRR ROR ko RR ke RK 


Value 


AO ROO IGG KORG ROG ORE 8 py RR KK eR e ek e ke e e ee 


Value 

FOI TO TOTO IOI TO TO IOI TOWER IIIA IA AA Ik 
Variable name:innodb mirrored log groups 

Value:1 

7 rows in set(0.00 sec) 





重 做 日 志文 件 的 大 小 设置 对 于 InnoDB 存 储 引 擎 的 性 能 有 着 非常 大 
的 影响 。 一 方面 重 做 日 志文 件 不 能 设置 得 太 大 ， MARERA, 在 恢 
复 时 可 能 需要 很 长 的 时 间 ; 另 一 方面 又 不 能 设置 得 太 小 了 ， 否 则 可 能 
致 一 个 事务 的 日 志 需 要 多 次 切换 重 做 日 志文 件 。 此 外 ， 重 做 日 志文 件 太 
小 会 导致 频繁 地 发 生 async checkpoint， 导 致 性 能 的 抖动 。 例 如 ， 用 户 可 
能 会 在 错误 日 志 中 看 到 如 下 和 警告 Eid: 

















090924 11:39:44 InnoDB:ERROR:the age of the last checkpoint is 9433712, 
InnoDB:which exceeds the log group capacity 9433498 

InnoDB:If you are using big BLOB or TEXT rows, you must set the 
InnoDB:combined size of log files at least 10 times bigger than the 
InnoDB:largest such row. 
090924 11:40:00 InnoDB:ERROR:the age of the last checkpoint is 9433823, 
InnoDB:which exceeds the log group capacity 9433498 
InnoDB:If you are using big BLOB or TEXT rows, you must set the 
InnoDB:combined size of log files at least 10 times bigger than the 
InnoDB:largest such row. 
090924 11:40:16 InnoDB:ERROR:the age of the last checkpoint is 9433645, 
InnoDB:which exceeds the log group capacity 9433498. 
InnoDB:If you are using big BLOB or TEXT rows,you must set the 
InnoDB:combined size of log files at least 10 times bigger than the 
InnoDB:largest such row. 











上 面 错误 集中 在 InnoDB:ERROR:the age of the last checkpoint is 
9433645, InnoDB:which exceeds the log group capacity 9433498。 这 是 因 
为 重 做 日 志 有 一 个 capacity 变 量 ， 该 值 代 表 了 最 后 的 检查 点 不 能 超过 这 
个 阔 值 ， 如 果 超 过 则 必须 将 缓冲 池 (innodb buffer pool) 中 脏 页 列表 

(flush — lis) 中 的 部 分 脏 数据 页 写 回 磁盘 ， 这 时 会 导致 用 尸 线程 的 阻 














Æ. 





也 许 有 人 会 问 ， 既 然 同样 是 记录 事务 日 志 ， 和 之 前 介绍 的 二 进 制 日 
志 有 什么 区 别 ? 


首先 ， 二 进 制 日 志 会 记录 所 有 与 MySQL 数 据 库 有 关 的 日 志 记 录 ， 
包括 InnoDB、MyISAM、Heap 等 其 他 存储 引擎 的 日 志 。 而 InnoDB 存 储 
引擎 的 重 做 日 志 只 记录 有 关 该 存储 引擎 本 身 的 事务 日 志 。 


其 次 ， 记 录 的 内 容 不 同 ， 无 论 用 户 将 二 进 制 日 志文 件 记录 的 格式 设 
为 STATEMENT 还 是 ROW， 又 或 者 是 MIXED， 其 记录 的 都 是 关于 一 个 
事务 的 具体 操作 内 容 ， 即 该 日 志和 是 馆 辑 日 志 。 而 InnoDB 存 储 引 擎 的 重 
做 日 志文 件 记录 的 是 关于 每 个 页 (Page) 的 更 改 的 物理 情况 。 


此 外 ， 写 入 的 时 间 也 不 同 ， 二 进 制 日 志文 件 仅 在 事务 提交 前 进行 提 
交 ， 即 只 与 磁盘 一 次 ， 不 论 这 时 该 事务 多 大 。 而 在 事务 进行 的 过 程 中 ， 
却 不 断 有 重 做 日 志和 条目 (redo entry) 被 写 入 到 重 做 日 志文 件 中 。 


在 mnoDB 存 储 引 擎 中 ， 对 于 各 种 不 同 的 操作 有 着 不 同 的 重 做 日 志 
格式 。 到 InnoDB 1.2.x 版 本 为 止 ， 总 共 定 义 了 51 种 重 做 日 志 类 型 。 虽 然 
各 种 重 做 日 志 的 类 型 不 同 ， 但 是 它们 有 着 基 本 的 格式 ， 表 3-2 显 示 了 重 
做 日 志 条 目的 结构 : 
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red log type page m red log body 


从 表 3-2 可 以 看 到 重 做 日 志 条 目 是 由 4 个 部 分 组 成 : 
Uredo_log type 占用 1 字 节 ， 表 示 重 做 日 志 的 类 型 


Dspace 表 示 表 空间 的 ID， 但 采用 压缩 的 方式 ， 因 此 占用 的 空间 可 
能 小 于 4 字 节 
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Dredo_log body 表示 每 个 重 做 日 志 的 数据 部 分 ， 恢 复 时 需要 调用 相 
应 的 函数 进行 解析 


在 第 2 章 中 己 经 提 到 ， 写 入 重 做 日 志文 件 的 操作 不 是 直接 写 ， 而 是 
先 写 入 一 个 重 做 日 志 缓冲 Credo log buffer) 中 ， 然 后 按照 一 定 的 条 件 顺 
序 地 写 入 日 志文 件 。 图 3-3 很 好 地 诠释 了 重 做 日 志 的 写 入 过 程 。 





redo log buffer 


redo log files 


ib logfile! ib logfile? 





图 3-3 重 做 日 志 写 入 过 程 


从 重 做 日 志 绥 冲 往 磁盘 写 入 时 ， 是 按 512 个 字 节 ， 也 束 是 一 个 而 区 
的 大 小 进行 写 入 。 因 为 局 区 是 写 入 的 最 小 单位 ， 因 此 可 以 保证 写 入 必定 
是 成 功 的 。 因 此 在 重 做 日 志 的 写 入 过 程 中 不 需要 有 doublewrite。 


前 面 提 到 了 从 日 志 绥 冲 写 入 磁盘 上 的 重 做 日 志文 件 是 按 一 定 条 件 进 
行 的 ， 那 这 些 条 件 有 哪些 呢 ? 第 2 章 分 析 了 主线 程 (master thread) ， 知 











道 在 主线 程 中 每 秒 会 将 重 做 日 志 绥 冲 写 入 磁盘 的 重 做 日 志文 件 中 ， 不 论 
事务 是 否 已 经 提交 。 另 一 个 触发 写 磁 盘 的 过 程 是 由 参数 
innodb_flush_log_at_trx_commit 控 制 ， 表 示 在 提交 (commit) 操作 时 ， 
处 理 重 做 日 志 的 方式 。 


参数 innodb _flush_log_at_trx_commit 的 有 效 值 有 0、1、2。0 代 表 当 
提交 事务 时 ， 并 不 将 事务 的 重 做 日 志 写 入 磁盘 上 的 日 志文 件 ， 而 是 等 符 
主线 程 每 秒 的 刷新 。1 和 2 不 同 的 地 方 在 于 : 1 表示 在 执行 commit 时 将 重 
做 日 志 缓冲 同步 写 到 磁 檀 ， 即 伴 有 fsync 的 调用 。2 表 示 将 重 做 日 志 异 步 
写 到 磁盘 ， 即 写 到 文件 系统 的 绥 存 中 。 因 此 不 能 完全 保证 在 执行 commit 
时 肯定 会 写 入 重 做 日 志文 件 ， 只 是 有 这 个 动作 发 生 。 


因此 为 了 保证 事务 的 ACID 中 的 持久 性 ， 必 须 将 
innodb_flush_log_at_trx_commit 设 置 为 1， 也 就 是 每 当 有 事务 提交 时 ， 就 
必须 确保 事务 都 已 经 写 入 重 做 日 志文 件 。 那 么 当 数 据 库 因为 意外 发 生 宕 
机 时 ， 可 以 通过 重 做 日 志文 件 恢复 ， 并 保证 可 以 恢复 已 经 提交 的 事务 。 
而 将 重 做 日 志文 件 设置 为 0 或 2， 都 有 可 能 发 生 恢复 时 部 分 事务 的 丢失 。 
不 同 之 处 在 于 ， 设 置 为 2 时 ， 当 MySQL 数 据 库 发 生 宕 机 而 操作 系统 及 服 
务 器 并 没有 发 生 宕 机 时 ， 由 于 此 时 未 写 入 磁盘 的 事务 日 志保 存在 文件 系 
统 缓存 中 ， 当 恢复 时 同样 能 保证 数据 不 丢失 。 




















37 seh 


本 章 介 绍 了 与 MySQL 数 据 库 相关 的 一 些 文件 ， 并 了 解 了 文件 可 以 
分 为 MySQL 数据 库 文件 以 及 与 各 存储 引擎 相关 的 文件 。 与 MySQL 数 据 
库 有 关 的 文件 中 ， 错 误 文 件 和 二 进 制 日 志文 件 非常 重要 。 当 MySQL 数 
据 库 发 生 任何 错误 时 ，DBA 首 先 就 应 该 去 碍 看 错误 文件 ， 从 文件 提示 的 
内 容 中 找 出 问题 的 所 在 。 当 然 ， 错 误 文件 不 仅 记录 了 错误 的 内 容 ， 也 记 
De sel i anny Vere AVE 
行 优 化 。 


二 进 制 日 志 的 作用 非常 关键 ， 可 以 用 来 进行 point in time 的 恢复 以 及 
复制 (replication? 环境 的 搭建 。 因 此 ， 建 议 在 任何 时 候 时 都 局 用 二 进 
制 日 志 的 记录 。 从 MySQL 5.1 开始 ， 二 进 制 日 志文 持 STATEMENT、 
ROW、MIX 三 种 格式 ， 这 样 可 以 更 好 地 保证 从 数据 库 与 主 数据 库 之 间 
数据 的 一 致 性 。 当 然 DBA 应 该 十 分 清楚 这 三 种 不 同 格式 之 间 的 差异 。 


本 章 的 最 后 介绍 了 和 InnoDB 存 储 引 擎 相关 的 文件 ， 包 括 表 空间 文 
件 和 重 做 日 忘 文件 。 表 空间 文件 是 用 来 管理 mmnoDB 存 储 引 擎 的 存储 ， 
分 为 共享 表 空 间 和 独立 表 空 间 。 重 做 日 志 非 常 的 重要 ， 用 来 记录 
InnoDB 存 储 引 擎 的 事务 日 志 ， 也 因为 重 做 日 志 的 存在 ， 才 使 得 InnoDB 
存储 引擎 可 以 提供 可 靠 的 事务 。 
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本 章 将 从 InnoDB 存 储 引 警 表 的 逻辑 存储 及 实现 开始 进行 介绍 ， 然 
后 将 重点 分 析 表 的 物理 存储 特征 ， 即 数据 在 表 中 是 如 何 组 织 和 存放 的 。 
表 就 是 关于 特定 实体 的 数据 集合 ， 这 也 是 关系 型 数据 库 模型 
^ ily o 








41 索引 组 织 表 


在 mnnoDB 存 储 引 擎 中 ， 表 都 是 根据 主键 顺序 组 织 存 放 的 ， 这 种 存 
储 方式 的 表 称 为 索引 组 织 表 〈index organized table) 。 在 InnoDB 存 储 引 
擎 表 中 ， 每 张 表 都 有 个 主键 (Primary Key) ， 如 果 在 创建 表 时 没有 显 式 
地 定义 主键 ， 则 InnoDB 存 储 引 擎 会 按 如 下 方式 选择 或 创建 主键 : 


口 首先 判断 表 中 是 否 有 非 空 的 唯一 索引 (Unique NOT NULL) ， 如 
果 有 ， 则 该 列 即 为 主键 。 


口 如 果 不 符合 上 述 条 件 ，InnoDB 存 储 引擎 自动 创建 一 个 6 字 节 大 小 
的 指针 。 

当 表 中 有 多 个 非 空 唯一 索引 时 ，InnoDB 存 储 引 擎 将 选择 建 表 时 第 
一 个 定义 的 非 空 唯一 索引 为 主键 。 这 里 需要 非常 注意 的 是 ， 主 键 的 选择 
根据 的 是 定义 索引 的 顺序 ， 而 不 是 建 表 时 列 的 顺序 。 看 下 面 的 例子 : 




















mysql>CREATE TABLE z( 

->a INT NOT NULL, 

->b INT NULL, 

->c INT NOT NULL, 

->d INT NOT NULL, 

->UNIQUE KEY(b 

->UNIQUE KEY(d),UNIQUE KEY(c)); 
ted(0.02 sec) 


Records:1 Duplicates:0 Warnings:0 
mysql>INSERT INTO z SELECT 5,6,7,8; 
Query OK,1 row affected(0.00 sec) 
Records:1 Duplicates:0 Warnings:0 
mysql>INSERT INTO z SELECT 9,10,11,12; 
er K,1 row affected(0.00 sec) 
Records:1 Duplicates:0 Warnings:0 





上 述 示例 创建 了 一 张 表 z， 有 a、b、c、d 四 个 列 。b、c、d 三 列 上 都 
有 唯一 索引 ， 不 同 的 是 b 列 允许 NULEL 值 。 由 于 没有 显 式 地 定义 主键 ， 
此 会 选择 非 空 的 唯一 索引 ， 可 以 通过 下 面 的 SQL 语句 判断 表 的 主键 值 : 











mysql>SELECT a,b,c,d, rowid FROM z; 
swadaEerpRbrmuededozdcwcmeacu 
Ja|b|c|d|_rowid| 

+---+------+----+----+------ 
|L121314141 

15161718181 

191101111121121 

+---+------+----+ 


3 rows in set(0.00 sec) 





_rowid 可 以 显示 表 的 主键 ， 因 此 通过 上 述 查 询 可 以 找到 表 z 的 主 


键 。 此 外 ， 虽 然 c、d 列 都 是 非 空 唯一 索引 ， 都 可 以 作为 主键 的 候选 ， 但 
古 在 定义 的 过 程 中 ， 由 于 d 列 首先 定义 为 唯一 索引 ， 故 InnoDB 存 储 引擎 
将 其 视 为 主键 。 


另外 需要 注意 的 是 ，_rowid 只 能 用 于 查看 单个 列 为 主键 的 情况 ， 对 
于 多 列 组 成 的 主键 就 显得 无 能 为 力 了 ， 如 








mysql>CREATE TABLE a( 

->a INT, 

->b INT, 

->PRIMARY KEY(a,b) 

-> )JENGINE-InnoDB; 

Query OK,0 rows affected(0.03 sec) 
mysql>INSERT INTO a SELECT 1,1 
Query OK,1 row affected(0.01 sec) 
Records:1 Duplicates:0 Warnings:O 
mysql>SELECT a, rowid FROM a; 
ERROR 1054(42S22):Unknown column' rowid'in'field list' 


ee | 
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从 InnoDB 存 储 引 擎 的 逻辑 存储 结构 看 ， 所 有 数据 都 被 逻辑 地 存放 
在 一 个 空间 中 ， 称 之 为 表 空间 (tablespace) 。 表 空间 又 由 段 
(segment) 、 区 (extent) 、 页 (page) 组 成 。 页 在 一 些 文档 中 有 了 时 也 
称 为 块 (block) ，InnoDB 存 储 引 擎 的 逻辑 存储 结构 大 致 如 图 4-1 所 示 。 


Tablespace 


Leaf node segment 
Non-Leaf node segment 







图 4-31 InnoDB 逻 辑 存储 结构 
4.2.1 表 空 间 


表 空 间 可 以 看 做 是 InnoDB 存 储 引 擎 逻辑 结构 的 最 高 屋 ， 所 有 的 数 
据 都 存放 在 表 空 间 中 。 第 3 章 中 已 经 介绍 了 在 默认 情况 下 InnoDB 存 储 引 
擎 有 一 个 共享 表 空 间 ibdata1， 即 所 有 数据 都 存放 在 这 个 表 空 间 内 。 如 果 
用 A F oH Ss - EISE 则 每 张 表 内 的 数据 可 以 单独 放 到 
一 个 表 空 间 内 。 


如 果 启 用 了 innodb_file_per_table 的 参数 ， 需 要 注意 的 是 每 张 表 的 表 
空间 内 存放 的 只 是 数据 、 索 引 和 插入 绥 冲 Bitmap 页 ， 其 他 类 的 数据 ， 如 
[HS (undo) 信息 ， 插入 缓冲 索引 页 页 。 系统 事务 信息 ， 二 次 写 缓冲 
(Double write buffer) 等 还 是 存放 在 原来 的 共享 表 空间 内 。 这 同时 也 说 
HTa 人 问题 : 即使 在 启用 了 参数 innodb_file_per_table 之 后 ， 共 享 表 
空间 还 是 会 不 断 地 增加 其 大 小 。 可 以 来 做 一 个 实验 ， 在 实验 之 前 已 经 将 
innodb file per table 设 为 ON 了 。 现 在 看 看 初始 共享 表 空 间 文 件 的 大 


小 : 














hs ROG EG GG] po CR OR RR RR eR RO RR I e RO e eek 


Variable name:innodb file per table 


1 row in set(0.00 sec) 
Boe nda ls-lh/usr/local/mysql/data/i ore 
-1 mysql mysql 58M Mar 11 13:58/usr/local/mysql/data/ibdata1 





可 以 看 到 ， 共 享 表 空 间 ibdatal 的 大 小 为 58MB， 接 着 模拟 产生 undo 
的 操作 ， 利 用 第 1 章 已 生成 的 表 mytest， 并 把 其 存储 引擎 更 改 为 
InnoDB， 执 行 如 下 操作 : 





i e autocommit-0; 
OK,0 rows arfectej(8. 00 sec) 
ys DATE mytest SET salary=0; 
Query OK,2844047 rows affected(19. 47 Va 
Rows matched: 2844047 En nged:2844047 Warnings:O 
mys diss ys stem ls-lh/usr/local/m me q1/data. i AEs ta* 
rw-rw----1 mysql mys ql 114M Mar 11 14:00/usr/local/mysql/data/ibdata1 





这 里 首先 将 自动 提交 设 为 0， 即 用 户 需 要 显 式 提交 事务 (注意 ， 在 
上 面 操作 结束 时 ， 并 没有 对 该 事务 执行 commit 或 rollback〉 。 接 着 执行 
会 产生 大 量 undo 操 作 的 语句 update mytest set salary=0， 完 成 后 再 观察 共 
享 表 空 间 ， 会 发 现 ibdatal 已 经 增长 到 了 114MB。 这 个 例子 虽然 简单 ， 但 





是 足以 说 明 共 享 表 空间 中 还 包含 有 undo 信 息 。 


有 用 户 会 问 ， 如 宋 对 k 这 个 事务 执行 rollback，ibdatal 这 个 表 空 间 会 
不 会 缩减 至 原来 的 大 小 〈58MB ) ? 这 可 以 通过 继续 运行 下 面 的 语句 得 
到 验证 : 





mysql>ROLLBACK; 
Query OK,0 rows affected(0.00 sec) 
mys co stem ls-lh/usr/local/m mys ql/data/i dus ta* 
-1 mysql mys al 114M Mar 11 14:00/usr/local/mysql/data/ibdata1 





很 “可 惜 ”， 共 享 表 空间 的 大 小 还 是 114MB， 即 InnoDB 存 储 引 擎 不 会 
在 执行 rollback 时 去 收缩 这 个 表 空 间 。 虽 然 InnoDB 不 会 回收 这 些 空间 ， 
但 是 会 自动 判断 这 些 undo 信 息 是 否 还 需要 ， 如 果 不 需要 ， 则 会 将 这 些 空 
间 标 记 为 可 用 空 x 间 ， 供 下 次 undo 使 用 。 


回想 一 下 ， 在 第 2 章 中 提 到 的 master thread 每 10 秒 会 执行 一 次 的 full 
purge 操 作 ， 很 有 可 能 的 一 种 情况 是 : 用 户 再 次 执行 上 述 的 UPDATE 语 
名 后， 会 发 现 ibdatal 不 会 再 增 大 了 ， 那 就 是 这 个 原因 了 。 


我 用 python 写 了 一 个 py_innodb_page_info 小 工具 ， 用 来 查看 表 空 间 
中 各 页 的 类 型 和 信息 ， 用 户 可 以 在 code.google.com 上 搜索 david-mysql- 
tools 进 行伍 找 。 使 用 方法 如 下 : 








ee neyou0-43 py ]#pytho on py innodb page info.py/usr/local/mysql/data/ibdatai 
Total mber of page:83584 

Inser t Buffer Free List: 204 

Freshly CAM. Page:5467 

Undo Log Page:38675 

File Segment inode:4 

B-tree Node:39233 

File Space Header:1 





可 以 看 到 共有 83 584 个 页 ， 其 中 插入 缓冲 的 空闲 列表 有 204 个 页 、 
5467 个 可 用 页 、38 675 个 undo 页 、39 233 个 数据 页 等 。 用 户 可 以 通过 添 
加 -v 参 数 来 查看 更 详细 的 内 容 。 由 于 该 工具 还 在 开发 之 中 ， 因 此 并 不 保 
证 在 本 书 出 版 时 此 工具 最 终 显 示 结 果 的 变化 。 
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图 4-1 中 显示 了 表 空 间 是 由 各 个 段 组 成 的 ， 和 党 见 的 段 有 数据 段 、 索 
引 段 、 回 滚 段 等 。 因 为 前 面 已 经 介绍 过 了 InnoDB 存 储 引擎 表 是 索引 组 
织 的 〈index organized) ， 因 此 数据 即 索 引 ， 索 引 即 数据 。 那 么 数据 段 
即 为 B+ 树 的 叶子 节点 (图 4-1 的 Leaf node segment) ， 索 引 段 即 为 B+ 树 
的 非 索 引 节 点 (图 4-1 的 Non-leaf node segment) 。 问 深 段 较为 特殊 ， 将 
会 在 后 面 的 章节 进行 单独 的 介绍 。 


在 mnoDB 存 储 引 擎 中 ， 对 段 的 管理 都 是 由 引擎 自身 所 完成 ，DBA 
不 能 也 没有 必要 对 其 进行 控制 。 这 和 Oracle 数 据 库 中 的 自动 段 空 间 管理 
(ASSM) 类 似 ， 从 一 定 程度 上 简化 了 DBA 对 于 段 的 管理 。 

















4.2.3 [X 


区 是 由 连续 页 组 成 的 空间 ， 在 任何 情况 下 每 个 区 的 大 小 都 为 1MB。 
为 了 保证 区 中 页 的 连续 性 ，InnoDB 存 储 引 擎 一 次 从 磁盘 申请 4 一 5 个 
区 。 在 默认 情况 下 ，InnoDB 存 储 引 擎 页 的 大 小 为 16EKB， 即 一 个 区 中 一 
共有 64 个 连续 的 页 。 


InnoDB 1.0.x 版 本 开始 引入 压缩 页 ， 即 每 个 页 的 大 小 可 以 通过 参数 
KEY BLOCK _SIZE 设 置 为 2K、4K、8K， 因 此 每 个 区 对 应 页 的 数量 就 
应 该 为 512、256、128。 











InnoDB 1.2.x 版 本 新 增 了 参数 innodb_page_size， 通 过 该 参数 可 以 将 
默认 页 的 大 小 设置 为 4K、8K， 但 是 页 中 的 数据 库 不 是 压缩 。 这 时 区 中 
页 的 数量 同样 也 为 256、128。 总 之 ， 不 论 页 的 大 小 怎么 变化 ， 区 的 大 小 
总 是 为 1M。 


但 是 ， 这 里 还 有 这 样 一 个 问题 : 在 用 户 启用 了 参数 
innodb_file_per_talbe 后 ， 创 建 的 表 默 认 大 小 是 96KB。 区 中 是 64 个 连续 
的 页 ， 创 建 的 表 的 大 小 至 少 是 1IMB 才 对 啊 ? 其 实 这 是 因为 在 每 个 段 开 始 
时 ， 先 用 32 个 页 大 小 的 碎片 页 (fragment page) 来 存放 数据 ， 在 使 用 完 
这 些 页 之 后 才 是 64 个 连续 页 的 申请 。 这 样 做 的 目的 是 ， 对 于 一 些小 表 ， 
或 者 是 undo 这 类 的 段 ， 可 以 在 开始 时 申请 较 少 的 空间 ， 节 省 磁盘 容量 的 
以 通过 一 个 很 小 的 示例 来 显示 InnoDB 存 储 引 擎 对 于 区 的 

请 方式 : 








mysql>CREATE TABLE t1( 

-2coli INT NOT NULL AUTO INCREMENT, 

->col2 VARCHAR(7000), 

->PRIMARY KEY(coli))ENGINE-InnoDB; 

mysql>system ls-lh/usr/local/mysql/data/test/t1.ibd; 

-rw-rw----1 mysql mysql 96K 10H12 14:59/usr/local/mysql/data/test/t1.ibd 





上 述 的 SQL 语句 创建 了 tt 表 ， 将 col2 字 段 设 为 
VARCHAR (7000) ， 这 样 能 保证 一 个 页 最 多 可 以 存放 2 条 记录 。 通 过 1s 
命令 可 以 发 现 ， 初 始 化 并 创建 tl 表 后 ， 表 空间 默认 大 小 为 96KB， 接 着 运 
行 如 下 SQL 语句 : 








mysql INSERT ti SELECT NULL, REPEAT('a', 7000); 
Query OK,1 row affected(0.04 sec) 

Records:1 Duplicates:0 Warnings:0 

mysql>INSERT into ti SELECT NULL, REPEAT('a', 7000); 
Query OK,1 row affected(0.01 sec) 


Records:1 Duplicates:0 Warnings:O 
mysql>system ls-lh/usr/local/mysql/data/test/t1.ibd; 
-rw-rw----1 mysql mysql 96K 10H12 16:24/usr/local/mysql/data/test/t1.ibd 











插入 两 条 记录 ， Nur 这 两 条 记录 应 该 位 于 同一 个 
页 中 。 如 果 这 时 通过 py_innodb_page_info 工 具 来 查看 表 空 间 ， 可 以 看 
FI): 











[root@nineyou0-43 py]#./py_innodb_page_info.py-v/usr/local/mysql/data/test/t1.ibd 
page offset 00000000, page type<File Space Header> 

page offset 00000001, page type<Insert Buffer Bitmap> 

page offset 00000002, page type<File Segment inode> 

page offset 00000003, page type<B-tree Node>,page level-c0000-— 
page offset 00000000, page type<Freshly Allocated Page> 

page offset 00000000, page type<Freshly Allocated Page> 

Total number of page:6: 

Freshly Allocated Page:2 

Insert Buffer Bitmap:1 

File Space Header:1 

B-tree Node:1 

File Segment inode:1 





这 次 用 -v 详 细 模 式 来 看 表 空 间 的 内 容 ， 注 意 到 了 page ^ offset 为 3 的 
页 ， 这 个 就 是 数据 页 。page level 表示 所 在 索引 层 ， 0 表示 叶子 节点。 
为 当前 所 有 记录 都 在 一 个 页 中 ， 因 此 没有 非 叶 节点 。 但 是 如 果 这 时 用 户 
再 插入 一 条 记录 ， 束 会 产生 一 个 非 叶 节点 : 











mysql>INSERT into t1 SELECT NULL,REPEAT('a',7000); 

Query OK,1 row affected(0.01 sec) 

Records:1 Duplicates:0 Warnings:O 

[rootQünineyouO-43 py]£./py innodb page info.py-v/usr/local/mysql/data/test/ti.ibd 
page offset 00000000,page type<File Space Header> 

page offset 00000001,page type<Insert Buffer Bitmap> 

page offset 00000002,page type<File Segment inode> 

page offset 00000003,page type<B-tree Node>,page level<0001> 
page offset 00000004, page type<B-tree Node>,page level-c0000-— 
page offset 00000005,page type<B-tree Node>,page level-c0000-— 
Total number of page:6: 

Insert Buffer Bitmap:1 

File Space Header:1 

B-tree Node:3 

File Segment inode:1 





现在 可 以 看 到 page offset 为 3 的 页 的 page de RENE 过 
时 虽然 新 插入 的 记录 导致 了 B+ 树 的 分 裂 操 作 ， 但 这 个 页 的 类 型 还 是 B- 


tree Node。 


接着 继续 上 述 同 样 的 操作 ， 再 插入 60 条 记录 ， 也 就 是 说 当前 表 tt 中 
共有 63 条 记录 ，32 个 页 。 为 了 导入 的 方便 ， 在 这 之 前 先 建立 一 个 导入 的 
存储 过 程 : 








mysql>DELIMITER// 

mysql>CREATE PROCEDURE load ti(count INT UNSIGNED) 
-— BEGIN 

->DECLARE s INT UNSIGNED DEFAULT 1; 

-— DECLARE c VARCHAR(7000)DEFAULT REPEAT('a', 7000); 
->WHILE s<=count DO 


->INSERT INTO t1 SELECT NULL,c; 

->SET s-s41; 

->END WHILE; 

- END; 

->// 

Query OK,0 rows affected(0.04 sec) 

mysq1-DELIMITER; 

mysql>CALL load t1(60); 

Query OK,1 row affected(1.59 sec) 

mysql SELECT COUNT(*)FROM t1\G; 
JOOOOOOOOOOOROOOOOOOOOIOOOOOOR] | p yy FISICA III III III Ie 
count (*):63 

1 row in set(0.00 sec)1 row in set(0.00 sec) 

mysql>system ls-lh/usr/local/mysql/data/test/t1.ibd; 
-rw-rw----1 mysql mysql 576K 10H12 16:56/usr/local/mysql/data/test/ti.ibd 








可 以 看 到 ， 在 导入 了 63 条 数据 后 ， 表 空间 的 大 小 还 是 小 于 1MB， 即 
表示 数据 空间 的 申请 还 是 通过 雄 厂 页 ， 而 不 是 通过 64 个 连续 页 的 区 。 这 
时 如 果 通 过 py_innodb_page_info 工 具 再 来 观察 表 空 间 tibd 文 件 ， 可 得 : 























[root@nineyou0-43 py]£./py innodb page info.py-v/usr/local/mysql/data/test/ti.ibd 
page offset 00000000, page type<File Space Header> 

page offset 00000001,page type<Insert Buffer Bitmap> 

page offset 00000002,page type<File Segment inode> 

page offset 00000003,page type<B-tree Node>,page level<0001> 
page offset 00000004, page type<B-tree Node>,page level-c0000-— 
page offset 00000005,page type<B-tree Node>,page level-c0000-— 
page offset 00000006,page type<B-tree Node>,page level<0000> 
page offset 00000007,page type<B-tree Node>,page level<0000> 
page offset 00000008, page type<B-tree Node>,page level-c0000-— 
page offset 00000009, page type<B-tree Node>,page level-c0000-— 
page offset 0000000a, page type<B-tree Node>,page level-c0000-— 
page offset 0000000b, page type<B-tree Node>,page level<0000> 
page offset 0000000c,page type<B-tree Node>,page level-c0000-— 
page offset 0000000d,page type<B-tree Node>,page level-c0000-— 
page offset 0000000e, page type<B-tree Node>,page level-c0000-— 
page offset 0000000f, page type<B-tree Node>,page level-c0000-— 
page offset 00000010, page type<B-tree Node>,page level-c0000-— 
page offset 00000011,page type<B-tree Node>,page level<o000> 
page offset 00000012,page type<B-tree Node>,page level-c0000-— 
page offset 00000013, page type<B-tree Node>,page level<o0000> 
page offset 00000014, page type<B-tree Node>,page level-c0000-— 
page offset 00000015,page type<B-tree Node>,page level-c0000-— 
page offset 00000016,page type<B-tree Node>,page level<o000> 
page offset 00000017,page type<B-tree Node>,page level<o000> 
page offset 00000018, page type<B-tree Node>,page level<0000> 
page offset 00000019, page type<B-tree Node>,page level<o000> 
page offset 0000001a,page type<B-tree Node>,page level-c0000-— 
page offset 0000001b, page type<B-tree Node>,page level-c0000-— 
page offset 0000001c,page type<B-tree Node>,page level<o0000> 
page offset 0000001d,page type<B-tree Node>,page level-c0000-— 
page offset 0000001e,page type<B-tree Node>,page level-c0000-— 
page offset 0000001f, page type<B-tree Node>,page level<o000> 
page offset 00000020,page type<B-tree Node>,page level<o000> 
page offset 00000021,page type<B-tree Node>,page level<o000> 
page offset 00000022,page type<B-tree Node>,page level-c0000-— 
page offset 00000023,page type<B-tree Node>,page level<o0000> 
Total number of page:36: 

Insert Buffer Bitmap:1 

File Space Header:1 

B-tree Node:33 

File Segment inode:1 

















可 以 观察 到 B-tree Node 页 一 共有 33 个 ， 除 去 一 个 page level 为 1 的 非 
叶 节 点 页 ， 一 共有 32 个 page level 为 0 的 页 ， 也 就 是 说 ， 对 于 数据 段 ， 已 
经 有 32 个 人 碎片 页 了 。 之 后 用 户 再 申请 空间 ， 则 表 空 间 按 连 续 64 个 页 的 大 
cis 好 了 ， 接 着 就 这 样 来 操作 ， 插 入 一 条 数据 ， 看 之 后 表 空 
A AZ): 











mysql>CALL load_t1(1); 
Query OK,1 row affected(0.10 sec) 
mysql>system ls-lh/usr/local/mysql/data/test/t1.ibd; 


-rw-rw----1 mysql mysql 2.0M 10H12 17:02/usr/local/mysql/data/test/ti.ibd 





因为 已 经 用 完了 32 个 碎片 页 ， 新 的 页 会 采用 区 的 方式 进行 空间 的 申 
请 ， 如 果 此 时 用 户 再 通过 py_innodb_page_info 工 具 来 看 表 空 间 文件 
tl.ibd， 应 该 可 以 看 到 很 多 类 型 为 Freshly Allocated Page 的 页 : 











[root@nineyou0-43 test2]#~/py/py_innodb_page_info.py t1.ibd-v 
page offset 00000000, page type<File Space Header> 

page offset 00000001,page type<Insert Buffer Bitmap> 

page offset 00000002,page type<File Segment inode> 

page offset 00000003, page type<B-tree Node>,page level<0001> 
page offset 00000004,page type<B-tree Node>,page level<0000> 
page offset 00000005,page type<B-tree Node>,page level<o0000> 
page offset 00000006,page type<B-tree Node>,page level<o000> 
page offset 00000007,page type<B-tree Node>,page level<0000> 
page offset 00000008,page type<B-tree Node>,page level<0000> 
page offset 00000009, page type<B-tree Node>,page level<0000> 
page offset 0000000a, page type<B-tree Node>,page level-c0000-— 
page offset 0000000b, page type<B-tree Node>,page level<0000> 
page offset 0000000c,page type<B-tree Node>,page level-c0000-— 
page offset 0000000d,page type<B-tree Node>,page level-c0000-— 
page offset 0000000e, page type<B-tree Node>,page level<o000> 
page offset 0000000f, page type<B-tree Node>,page level<o000> 
page offset 00000010,page type<B-tree Node>,page level-c0000-— 
page offset 00000011,page type<B-tree Node>,page level-c0000-— 
page offset 00000012,page type<B-tree Node>,page level-c0000-— 
page offset 00000013,page type<B-tree Node>,page level<o000> 
page offset 00000014, page type<B-tree Node>,page level<o000> 
page offset 00000015,page type<B-tree Node>,page level-c0000-— 
page offset 00000016,page type<B-tree Node>,page level<0000> 
page offset 00000017,page type<B-tree Node>,page level<o000> 
page offset 00000018, page type<B-tree Node>,page level<o000> 
page offset 00000019, page type<B-tree Node>,page level-c0000-— 
page offset 0000001a,page type<B-tree Node>,page level-c0000-— 
page offset 0000001b, page type<B-tree Node>,page level-c0000-— 
page offset 0000001c,page type<B-tree Node>,page level-c0000-— 
page offset 0000001d,page type<B-tree Node>,page level-c0000-— 
page offset 0000001e,page type<B-tree Node>,page level-c0000-— 
page offset 0000001f, page type<B-tree Node>,page level-c0000-— 
page offset 00000020,page type<B-tree Node>,page level<o0000> 
page offset 00000021,page type<B-tree Node>,page level<0000> 
page offset 00000022,page type<B-tree Node>,page level-c0000-— 
page offset 00000023,page type<B-tree Node>,page level<o000> 
page offset 00000000,page type<Freshly Allocated Page> 








page offset 00000000,page type<Freshly Allocated Page> 
page offset 00000000,page type<Freshly Allocated Page> 
page offset 00000000,page type<Freshly Allocated Page> 
Total number of page:128: 

Freshly Allocated Page:91 

Insert Buffer Bitmap:1 

File Space Header:1 

B-tree Node:34 

File Segment inode:1 








pM———————————————————— ——————————————————— 


42.4 页 


同 大 多 数 数据 库 一 样 ，InnoDB 有 页 (Page) 的 概念 〈 也 可 以 称 关 
IR) ， 页 是 InnoDB 人 磁盘 管理 的 最 小 单位 。 在 InnoDB 和 存储 引擎 中 ， 默 认 
每 个 页 的 大 小 为 16KB。 而 从 InnoDB 1.2.x 版 本 开始 ， 可 以 通过 参数 
innodb_page_size 将 页 的 大 小 设置 为 4K、8K、16K。 若 设置 完成 ， 则 所 
有 表 中 页 的 大 小 都 为 innodb_page_size， 不 可 以 对 其 再 次 进行 修改 。 除 
非 通过 mysqldump 导 入 和 导出 操作 来 产生 新 的 库 。 


在 mnoDB 存 储 引 擎 中 ， 和 见 的 页 类 型 有 : 


口 数据 页 CB-tree Node) 





Dundo 页 (undo Log Page? 

口 系统 页 (System Page) 

口 事 务 数 据 页 (Transaction system Page) 

口 插入 缓冲 位 图 页 (Insert Buffer Bitmap? 

口 插 入 缓冲 空闲 列表 页 (Insert Buffer Free List) 

口 未 压缩 的 二 进 制 大 对 象 页 (Uncompressed BLOB Page) 


口 压缩 的 二 进 制 大 对 象 页 Ccompressed BLOB Page? 


4.2.5 行 


InnoDB 存 储 引 擎 是 面向 列 的 〈row-oriented) ， 也 就 说 数据 是 按 行 
进行 存放 的 。 每 个 页 存放 的 行 记 录 也 是 有 硬性 定义 的 ， 最 多 允许 存放 
16KB/2-200 行 的 记录 ， 即 7992 行 记录 。 这 里 提 到 了 row-oriented 的 数据 
库 ， 也 就 是 说 ， 存 在 有 column-oriented 的 数据 库 。MySQL infobright 存 储 
引擎 融 是 按 列 来 存放 数据 的 ， 这 对 于 数据 仓库 下 的 分 析 类 SQL 语句 的 执 
行 及 数据 压缩 非常 有 帮助 。 类 似 的 数据 库 还 有 Sybase IQ. Google Big 
Table。 面 问 列 的 数据 库 是 当前 数据 库 发 展 的 一 个 方向 ， 但 这 超出 了 本 
书 闻 善 的 内 容 ， 有 兴趣 的 读者 可 以 在 网 上 寻找 相关 资料 。 














43 ”InnoDB 行 记录 格式 


InnoDB 存 储 引 敬 和 大 多 数 数据 库 一 样 〈 如 Oracle 和 Microsoft SQL 
Server 数 据 库 ) ， 记 录 是 以 行 的 形式 存储 的 。 这 意味 着 页 中 保存 着 表 中 
一 行 行 的 数据 。 在 InnoDB 1.0.x 版 本 之 前 ，InnoDB 存 储 引 擎 提供 了 
Compact 和 Redundant 两 种 格式 来 存放 行 记 录 数 据 ， 这 也 是 目前 使 用 最 多 
的 一 种 格式 。Redundant 格 式 是 为 兼容 之 前 版 本 而 保留 的 ， 如 果 阅 读 过 
InnoDB 的 源 人 代码， 用户 会 发 现 源 代码 中 是 用 PHYSICAL 
RECORD (NEW STYLE) 和 PHYSICAL RECORD (OLD STYLE) 来 
区 分 两 种 格式 的 。 在 MySQL 5.1 版 本 中 ， 默 认 设 置 为 Compact 行 格式 。 
用 户 可 以 通过 命令 SHOW TABLE STATUS LIKE'table_name' 来 查看 当前 
0 0 ea Pet 
AT. Ul: 














Name:mytest 

Engine:InnoDB 

Version:10 

Row format:Compact 

Rows:6 

Avg. row length:2730 

Data length:16384 

Max data length:0O 

Index length:0 

Data free:0 

Auto increment : NULL 

Create time:2009-03-17 13:33:50 
Update time:NULL 

Check time:NULL 
Collation:latini swedish ci 
Checksum: NULL 

Create options: 

Comment : 


Name :mytest2 

Engine:InnoDB 

Version:10 

Row. format:Redundant 

Rows :0 

Avg. row length:9 

Data length:16384 

Max data length:0O 

Index length:6 

Data free:0 

Auto increment:NULL 

Create time:2009-03-17 13:57:23 
Update time:NULL 

Check time:NULL 
Collation:latini swedish ci 
Checksum: NULL 

Create options:row format-REDUNDANT 
Comment : 

2 rows in set(0.00 sec) 





可 以 看 到 ， 这 里 的 mytest 表 是 Compact 的 行 格式 ，mytest2 表 是 
Redundant 的 行 格式 。 通 过 之 前 的 介绍 可 以 知道 ， 数 据 库 实例 的 作用 之 
一 就 是 读 取 页 中 存放 的 行 记录 。 如 果 用 户 自己 知道 页 中 行 记录 的 组 织 规 
则 ， 也 可 以 自行 通过 编写 工具 的 方式 来 读 取 其 中 的 记录 ， 如 之 前 介绍 的 








py _innodb_page_info 工 具 。 本 节 的 其 余 小 节 将 具体 分 析 各 格式 存放 数据 
的 规则 。 
4.3.1 Compact 行 记录 格式 


Compact 行 记录 是 在 MySQL 5.0 中 引入 的 ， 其 设计 目标 是 高 效 地 存 
储 数据 。 简 单 来 说 ， 一 个 页 中 存放 的 行 数据 越 多 ， 其 性 能 就 越 高 。 图 4- 
2 显示 了 Compact 行 记录 的 存储 方式 : 






BERE | NULL | ORM 








图 4-2 Compact 行 记录 的 格式 





从 图 4-2 可 以 观察 到 ，Compact 行 记录 格式 的 首部 是 一 个 非 NULL 变 
长 字段 长 度 列 表 ， 并 且 其 是 按照 列 的 顺序 逆序 放置 的 ， 其 长 度 为 : 


口 若 列 的 长 度 小 于 255 字 节 ， 用 1 字 节 表示 ; 

口 知 大 于 255 个 字 节 ， 用 2 字 节 表示 。 

变 长 字段 的 长 度 最 大 不 可 以 超过 2 字 节 ， 这 是 因 在 MySQL 数 据 库 中 
VARCHAR 类 型 的 最 大 长 度 限制 为 65535。 变 长 字段 之 后 的 第 二 个 部 分 
是 NULL 标 志 人 位， 该 位 指示 了 该 行 数 据 中 是 否 有 NULL 值 ， 有 则 用 1 表 


示 。 该 部 分 所 请 的 学 市 应 该 为 1 学 市 。 接 下 来 的 部 分 是 记录 头 信息 
(record header) ， 固 定 占 用 5 字 节 (40 位 〉，， 每 位 的 含义 见 表 4-1。 
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最 后 的 部 分 就 是 实际 存储 每 个 列 的 数据 。 需 要 特别 注意 的 是 ， 
NULL 不 占 该 部 分 任何 空间 ， 即 NULL 除 了 占有 NULL 标 志 人 位， 实际 存储 
不 占有 任何 空间 。 另 外 有 一 点 需要 注意 的 是 ， 每 行 数据 除了 用 户 定 义 的 
列 外 ， 还 有 两 个 隐藏 列 ， 事 务 ID 列 和 回 滚 指针 列 ， 分 别 为 6 字 节 和 7 字 节 

















的 大 小 。 夺 InnoDB 表 没有 定义 主键 ,每 行 还 会 增加 一 个 6 字 市 的 rowid 
列 。 


接 下 去 用 一 个 具体 示例 来 分 析 Compact 行 记录 的 内 部 结构 : 





mysql>CREATE TABLE mytest( 
->t1 VARCHAR(10), 
->t2 VARCHAR(10), 
->t3 CHAR(10), 
->t4 VARCHAR(10 
->)ENGINE=INNODB CHARSET-LATIN1 ROW FORMAT-COMPACT; 
Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO mytest 
->VALUES('a', 'bb', 'bb', 'ccc'); 
Query OK,1 row affected(0.01 sec) 
mysql>INSERT INTO mytest 
->VALUES('d', 'ee', 'ee', 'ff 
Query OK,1 row affected(0. 00 ans 
mysql> INSERT INTO mytest 
->VALUES('d', NULL, NULL, 'fff'); 
Query OK,1 row affected(0.00 sec) 
mysql>SELECT*FROM mytest\G; 


ta: fff 
3 rows in set(0.00 sec) 





在 上 述 示 例 中 ， 创 建 表 mytest， 该 表 共 有 4 个 列 。t1、t2、t4 都 为 
VARCHAR 变 长 字段 类 型 ，t3 为 固定 长 度 类 型 CHAR。 接 着 插入 了 3 条 有 
代表 性 的 数据 ， 然 后 将 打开 表 空 间 文 件 mytest.ibd (这 里 启用 了 
innodb_file_per table， 知 没有 局 用 该 选项 ， 打 开 默 认 的 共享 表 空 间 文件 
ibdatal) 。 


在 Windows 操 作 系 统 下 ， 可 以 选择 通过 程序 UltraEdit 打 开 该 二 进 制 
文件 。 在 Linux 环 境 下 ， 使 用 命令 hexdump-C-v mytest.ibd>mytest.txt. 
这 里 将 结果 重 定向 到 了 文件 mytest.txt， 打 开 mytest.txt 文 件 ， 找 到 如 下 内 
容 : 





0000c070 73 75 70 72 65 6d 75 6d 03 02 01 00 00 OO 10 00|supremum........ 
0000c080 2c 00 00 00 2b 68 00 00 00 00 00 06 05 80 00 00|,...*h.......... 
06000c090 00 32 01 10 61 62 62 62 62 20 20 20 20 20 20 20|.2. sonobbl T 

0000c0a0 20 63 63 63 03 02 01 00 00 00 18 00 2b OO 00 00|cCC........*... 


0000cObO 2b 68 01 00 00 00 00 06 06 80 00 00 OO 32 O1 10|*h........... MC 
0000cOcO 64 65 65 65 65 20 20 20 20 20 20 20 20 66 66 66|deeeefff| 

0000cOdO 03 01 06 00 00 20 ff 98 00 00 00 2b 68 02 00 00|.......... *h...| 
0000cOe0 00 00 06 07 80 00 00 00 32 01 10 64 66 66 66 00|........ 2..dfff.| 





该 行 记 录 从 0000c078 开 始 ， 若 整理 一 下 ， 相 信用 户 会 有 更 好 的 理 





03 02 01/* 变 长 字段 长 度 列表 ， 逆 序 */ 
00/* NULLA :位 ， 第 一 行 没有 NULL 值 */ 
00 00 10 2c/*Record Header， 固 定 5 字 节 长 度 
00 00 00 20 3 00/*Ro aD Inno eu &, ed +f 
00 00 00 00 06 05/*TransactionID* 
80 00 0000 = 01 10/* Roll Po inte r*/ 
+7 


62 62 20 20 20 20 2 20 20 20/* 列 3 数据 'bb'*/ 
63 63 63/* 列 4 数据 'ccc'*/ 

















现在 第 一 行 数据 束 展 现在 用 户 眼 前 了 。 需 要 注意 的 是 ， 变 长 字段 长 
度 列表 是 逆序 存放 的 ， 因 此 变 长 字段 长 度 列表 为 03 02 01， 而 不 是 01 02 
03。 此 外 还 需要 注意 InnoDB 每 行 有 隐藏 列 TransactionID 和 Roll Pointer. 
同时 可 以 发 现 ， 固 定 长 度 CHAR 字 段 在 未 能 完全 占用 其 长 度 空间 时 ， 会 
用 0x20 来 进行 填充 。 


接着 再 来 分 析 下 Record Header 的 最 后 两 个 字 节 ， 这 两 个 字 节 代 表 
next_recorder，0x2c 代 表 下 一 个 记录 的 偏 移 量 ， 即 当前 记录 的 位 置 加 上 
偏 移 量 0x2c 束 是 下 条 记录 的 起 如 位 置 。 所 以 PmnoDB 存 储 引 擎 在 页 内 部 是 

通过 一 种 链表 的 结构 来 串 连 各 个 行 记 录 的 。 


第 二 行将 不 做 整理 ， 除 了 RowID 不 同 外 ， 它 和 第 一 行 大 同 小 异 ， 有 
兴趣 的 读者 可 以 用 上 面 的 方法 自己 试 试 。 现 在 来 关心 有 NULL 值 的 第 三 
8. 














03 01/* 变 长 字段 长 度 列 表 ， 逆 序 */ 
96/*NULL 标 志 位 ， 人 
00 00 20 ff 98/*Record Header*/ 


jo 
80 00 00 00 m 01 10/*Roll Pointer*/ 
64/* 列 1 数据 'd 
66 66 66/* JAAR fff'*/ 








第 三 行 有 NULL 值 ， 因 此 NULL 标 志 位 不 再 是 00 而 是 06， 转 换 成 二 
进 制 为 00000110， 为 1 的 值 代 表 第 2 列 和 第 3 列 的 数据 为 NULL。 在 其 后 存 
储 列 数据 的 部 分 ， 用 户 会 发 现 没 有 存储 NULL 列 ， 而 只 存储 了 第 1 列 和 第 
4 列 非 NULL 的 值 。 因 此 这 个 例子 很 好 地 说 明了 : 不 管 是 CHAR 类 型 还 是 
VARCHAR 类 型 ， 在 compact 格 式 下 NULL 值 都 不 占用 任何 存储 空间 。 


4.3.2 Redundant 行 记录 格式 


Redundant 是 MySQL 5.0 版 本 之 前 InnoDB 的 行 记 录 存 储 方式 ， 
MySQL 5.0 文 持 Redundant 是 为 了 兼容 之 前 版 本 的 页 格式 。Redundant 行 
记录 采用 如 图 4-3 所 示 的 方式 存储 。 

















图 4-3 Redundant 行 记录 格式 


从 图 4-3 可 以 看 到 ， 不 同 于 Compact 行 记录 格式 ，Redundant 行 记录 
格式 的 首部 是 一 个 字段 长 度 偶 移 列表 ， 同 样 是 按照 列 的 顺序 逆序 放置 
的 。 若 列 的 长 度 小 于 255 字 节 ， 用 1 字 节 表示 ; BATS, H270 
表示 。 第 二 个 部 分 为 记录 头 信 息 (record header) ， 不 同 于 Compact 行 记 
录 格 式 ，Redundant 行 记录 格式 的 记录 头 占 用 6 字 节 (48 位 ) , BEAL 
义 见 表 4-2。 从 表 4-2 中 可 以 发 现 ，n_fields 值 代表 一 行 中 列 的 数量 ， 占 用 
10 位 。 同 时 这 也 很 好 地 解释 了 为 什么 MySQL 数 据 库 一 行文 持 最 多 的 列 
为 1023。 男 一 个 需要 注意 的 值 为 lbyte_offs_flags， 该 值 定 义 了 偏 移 列表 
占用 1 字 节 还 是 2 字 节 。 而 最 后 的 部 分 就 是 实际 存储 的 每 个 列 的 数据 了 。 
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接着 创建 一 张 和 4.3.1 节 中 表 mytest 内 容 完 全 一 样 但 行 格式 为 


Redundant 的 表 mytest2。 


mysql>CREATE TABLE mytest2 


->AS 

->SELECT*FROM mytest; 

Query OK,3 rows affected(0.00 sec) 
Records:3 Duplicates:0 Warnings:0 
mysql>SHOW TABLE STATUS LIKE'mytest2'\G; 
JOOOOOOOOOOOOOOOOOIOOOOOOOOOR | pj FO ICICI I ICICI III III III Ie 
Name :mytest2 

Engine: InnoDB 

Version:10 

Row_format : Redundant 

Rows :3 

Avg_row_length:5461 

Data_length:16384 

Max_data_length:0 

Index_length:0 

Data_free:0 

Auto_increment : NULL 

Create_time: 2009-03-18 15:49:42 
Update_time:NULL 

Check time:NULL 

Collation:latini swedish ci 

Checksum: NULL 

Create options:row format-REDUNDANT 
Comment : 

1 row in set(0.00 sec) 
mysql>SELECT*FROM mytest2\G; 
JOOOOOOOOOOOROOOOOOOOOOOOOOOR | pj COOOOCOOOOOOOOOOOOOOOROROROK 
tira 

t2:bb 

t3:bb 

t4:ccc 
JOOOOOOOOOOOOOOOOOOO OO) pj FICCI III ICICI III IIIA II Ie 
tiid 

t2:ee 

t3:ee 

t4:fff 
JOOOOOOOOOOOOOOOOOOOOOOOOERK | pj 2 IGG II ICICI III III III Ie 
titid 

t2:NULL 

t3:NULL 

t4:fff 

3 rows in set(0.00 sec) 





可 以 看 到 ， 现 在 row_format 变 为 Redundant。 同 样 通过 hexdump 将 表 
空间 mytest2.ibd 导 出 到 文本 文件 mytest2.txt。 打 开 文 件 ， 找 到 类 似 如 下 
行 : 





0000c070 08 03 00 00 73 75 70 72 65 6d 75 6d 00 23 20 16|....supremum.#. | 
0000c080 
0000c090 
0000c0a0 
0000c0b0 
0000c0c0 
0000c0d0 
0000c0e0 
0000cgf9 
0000c100 








整理 可 以 得 到 如 下 内 容 : 





23 20 16 14 13 Qc 06/* 长 度 偏 移 列表 ， 逆 序 */ 

00 00 10 Of 00 ba/*Record Header， 固 定 6 个 字 节 */ 

00 00 00 2b 68 Ob/*RowID*/ 

00 00 00 00 06 53/*TransactionID*/ 

80 00 00 00 32 01 10/*Roll Point*/ 

61/* 列 1 数据 'a'*/ 

62 62/* 列 2 数据 'bb'*/ 

62 62 20 20 20 20 20 20 20 20/* 列 3 数据 'bb'Char 类 型 */ 
63 63 63/* 列 4 数据 'ccc'*/ 





23 20 16 14 13 Oc 06 道 转 为 06，0c，13，14，16，20，23， 分 别 代 
表 第 一 列 长 度 6， 第 二 列 长 度 6 (6+6=0x0C) ， 第 三 列 长 度 为 


7 (6+6+7=0x13) ， 第 四 列 长 度 1 (6+6+7+1=0x14) ， 第 五 列 长 度 
2 (6+6+7+1+2=0x16) ， 第 六 列 长 度 10 (6+6+7+1+2+10=0x20) ， 第 七 
列 长 度 3 (6+6+7+14+2+10+3=0x23) 。 


在 接 下 来 的 记录 头 信 息 (Record Header) 中 应 该 注意 48 位 中 的 第 22 
一 32 位 ， 为 0000000111， 表 示 表 共有 7 个 列 (包含 了 隐藏 的 3 列 ) ， 接 下 
来 的 第 33 位 为 1， 代 表 偏 移 列表 为 一 个 字 市 。 


后 面 的 信息 就 是 实际 每 行 存放 的 数据 了 ， 这 同 Redundant 行 记录 格 
式 大 致 相同 ， 注 意 是 大 致 相同 ， 因 为 如 果 分 析 第 三 行 ， 会 发 现 对 于 
NULL 值 的 处 理 两 者 是 非常 不 同 的 : 








21 9e 94 14 13 Oc 06/* 长 度 偏 移 列表 ， 逆 序 */ 
00 00 20 Of 00 74/*Record Header， 固 定 6 字 节 */ 
00 00 00 2b 68 Od/*RowID*/ 

00 00 00 00 06 53/*TransactionID*/ 

80 00 00 00 32 01 10/*Roll Point*/ 
64/* 列 1 数据 'd'*/ 

00 00 00 00 00 00 00 00 00 00/* 列 3 数据 NULL*/ 
66 66 66/* 列 4 数据 'fff'*/ 








这 里 与 之 前 Compact 行 记录 格式 有 着 很 大 的 不 同 了 ， 首 先 来 看 长 度 
偏 移 列表 ， 逆 序 排列 后 得 到 06 Oc 13 14 94 9e 21， 前 4 个 值 都 很 好 理解 ， 
第 5 个 NULL 值 变 为 了 94， 接 着 第 6 个 CHAR 类 型 的 NULL 值 为 
9e (94+10=0x9e) ， 之 后 的 21 代 表 (14+3=0x21) 。 可 以 看 到 对 于 
VARCHAR 类 型 的 NULL 值 ，Redundant 行 记录 格式 同样 不 占用 任何 存储 
空间 ， 而 CHAR 类 型 的 NULL 值 需要 占用 空间 。 


当前 表 mytest2 的 字符 集 为 Latin1， 每 个 字符 最 多 只 占用 1 字 节 。 知 
用 户 将 表 mytest2 的 字符 集 转 换 为 utf8， 第 三 列 CHAR 固 定 长 度 类 型 不 再 
是 只 占用 10 字 节 了 ， 而 是 10x3=30 字 节 。 所 以 在 Redundant 行 记录 格式 
e I 占用 可 能 存放 的 最 大 值 字 节 数 。 有 兴趣 的 读者 可 以 
行 尝试 。 








4.3.3” 行 溢出 数据 


InnoDB 存 储 引擎 可 以 将 一 条 记录 中 的 某 些 数 据 存储 在 真正 的 数据 
页 面 之 外 。 一 般 认 为 BLOB、LOB 这 类 的 大 对 象 列 类 型 的 存储 会 把 数据 
存放 在 数据 页 面 之 外 。 但 是 ， 这 个 理解 有 点 偏差 ，BLOB 可 以 不 将 数据 
让 在 洲 出 中 面 ， 而 且 即 便 是 VARCHAR 列 数据 类 型， 依然 有 可 能 被 存放 
为 行 溢出 数据 。 


首先 对 VARCHAR 数 据 类 型 进行 研究 。 很 多 DBA 喜 欢 MySQL 数 据 
库 提供 的 VARCHAR 类 型 ， 因 为 相对 于 Oracle VARCHAR2 最 大 存放 4000 
F, SQL Server 最 大 存放 8000 字 节 ，MySQL 数 据 库 的 VARCHAR 类 型 
可 以 存放 65535 字 节 。 但 是 ， 这 是 真 的 吗 ? 真 的 可 以 存放 65535 字 节 吗 ? 
如 果 创 建 VARCHAR 长 度 为 65535 的 表 ， 用 户 会 得 到 下 面 的 错误 信息 : 











mysql>CREATE TABLE test( 

->a VARCHAR(65535) 

->)CHARSET=latin1 ENGINE-InnoDB; 

ERROR 1118(42000):Row size too large.The maximum row size for the used table type,not counting BLOBs,is 65535.You have to 
change some columns to TEXT or BLOBs 





从 错误 消息 可 以 看 到 InnoDB 存 储 引 擎 并 不 文 持 65535 长 度 的 
VARCHAR。 这 是 因为 还 有 别 的 开销 ， 通 过 实际 测试 发 现 能 存放 
VARCHAR 类 型 的 最 大 长 度 为 65532。 例 如 ， 按 下 面 的 命令 创建 表 就 不 
会 报错 了 。 





mysql>CREATE TABLE test( 

->a VARCHAR(65532) 
->)CHARSET=latin1 ENGINE-InnoDB; 
Query OK,0 rows affected(0.15 sec) 








再 要 注意 的 是 ， 如 果 在 执行 上 述 示例 的 时 候 没 有 将 SQL_MODE 设 
为 严格 模式 ， 或 许可 以 建立 表 ， 但 是 MySQL 数 据 库 会 抛 出 一 个 


warning, 如 : 





mysql>CREATE TABLE test( 

->a VARCHAR(65535) 

-2)J)CHARSET-latini ENGINE-InnoDB; 

Query OK,0 rows affected,1 warning(0.14 sec) 
mysql1- SHOW WARNINGS\G; 


Level:Note 

Code:1246 

Message:Converting column'a'from VARCHAR to TEXT 
1 row in set(0.00 sec) 


p—M—————————————M————————————————————À 


warning 信 息 提 示 了 这 次 可 以 创建 是 因为 MySQL 数 据 库 上 自动 地 将 
VARCHAR 类 型 转换 成 了 TEXT 类 型 。 查 看 test 的 表 结 构 会 发 现 : 





mysql>SHOW CREATE TABLE test\G; 
KKKERRRRKKEERKKKKERKEKKKERRJ | p IGG GIGI RAKKAR III I Ik 
Table:test 

Create Table:CREATE TABLE'test '( 

'a'mediumtext 

JENGINE-InnoDB DEFAULT CHARSET-utf8 

1 row in set(0.00 sec) 





还 需要 注意 上 述 创 建 的 VARCHAR 长 度 为 65 532 的 表 ， 其 字符 类 型 
是 latin1 的 ， 如 果 换 成 GBK 又 或 UTF-8 的 ， 会 产生 怎样 的 结果 呢 ? 





mysql>CREATE TABLE test( 

->a VARCHAR( 65532) 

->)CHARSET=GBK ENGINE=InnoDB; 

ERROR 1074(42000):Column length too big for column'a'(max-32767);use BLOB or TEXT instead 
mysql>mysql>CREATE TABLE test( 

->a VARCHAR(65532) 

->)CHARSET=UTF8 ENGINE=InnoDB; 

ERROR 1074(42000):Column length too big for column'a'(max-21845);use BLOB or TEXT instead 





这 次 即使 创建 列 的 VARCHAR 长 度 为 66532， 也 会 提示 报错 ， 但 是 
两 次 报错 对 max 值 的 提示 是 不 同 的 。 因 此 从 这 个 例子 中 用 户 也 应 该 理解 
VARCHAR (N) 中 的 N 指 的 是 字符 的 长 度 。 而 文档 中 说 明 VARCHAR 
类 型 最 大 支持 65535， 单 位 是 字 节 。 


此 外 需要 注意 的 是 ，MySQL 官 方 手册 中 定义 的 65535 长 度 是 指 所 有 
VARCHAR 列 的 长 度 总 和 ， 如 宁 列 的 长 度 总 和 超出 这 个 长 度 ， 依 然 无 法 
创建 ， 如 下 所 示 : 














mysql>CREATE TABLE test2( 

->a VARCHAR(22000), 

->b VARCHAR(22000), 

->c VARCHAR(22000) 

->)CHARSET=latin1 ENGINE-InnoDB; 

ERROR 1118(42000):Row size too large.The maximum row size for the used table type,not counting BLOBs,is 65535.You have to 
change some columns to TEXT or BLOBs 





3 个 列 长 度 总 和 是 66000， 因 此 InnoDB 存 储 引 擎 再 次 报 了 同样 的 错 
误 。 即 使 能 存放 65532 个 字 节 ， 但 是 有 没有 想 过 ，InnoDB 存 储 引 擎 的 页 
为 16KB， 即 16384 字 节 ， 怎 么 能 存放 65532 字 节 了 有 昵 ? 因此 ， 在 一 般 情 况 
下 ，InnoDB 存 储 引擎 的 数据 都 是 存放 在 页 类 型 为 B-tree node 中 。 但 是 当 
do c 数据 存放 在 页 类 型 为 Uncompress BLOB 页 中 。 来 看 下 面 
一 个 例 了 于 : 














mysql>CREATE TABLE t( 


->a VARCHAR( 65532) 
->)ENGINE=InnoDB CHARSET=latin1; 
Query OK,0 rows affected(0.15 sec) 
mysql>INSERT INTO t 

->SELECT REPEAT('a', 65532); 

Query OK,1 row affected(0.08 sec) 
Records:1 Duplicates:0 Warnings:0 





在 上 述 例子 中 ， 首 先 创建 了 一 个 列 a 长 度 为 65 5328] VARCHAR AY 
表 {t， 然 后 插入 了 列 a 长 度 为 65 532 的 记录 ， 接 着 通过 工具 
py_innodb_page_info 看 表 空 间 文件 ， 可 以 看 到 的 页 类 型 有 : 





[root@nineyou0-43 mytest]#py_innodb_page_info.py-v t.ibd 
page offset 00000000,page type<File Space Header> 

page offset 00000001,page type<Insert Buffer Bitmap> 
page offset 00000002,page type<File Segment inode> 

page offset 00000003, page type<B-tree Node>,page level<o0000> 
page offset 00000004, page type<Uncompressed BLOB Page> 
page offset 00000005,page type<Uncompressed BLOB Page> 
page offset 00000006,page type<Uncompressed BLOB Page> 
page offset 00000007,page type<Uncompressed BLOB Page> 
Total number of page:8: 

Insert Buffer Bitmap:1 

Uncompressed BLOB Page:4 

File Space Header:1 

B-tree Node:1 

File Segment inode:1 











通过 工具 可 以 观察 到 表 空 间 中 有 一 个 数据 页 节点 B-tree Node, 5h 
有 4 个 未 压缩 的 二 进 制 大 对 象 页 Uncompressed BLOB Page， 在 这 些 页 中 
才 贞 正和 存放 了 65532 子 习 的 数据 。 既 然 实际 存放 的 数据 部 在 BLOB 页 中 ， 
那 数据 页 中 又 存放 了 些 什么 内 容 呢 ? 同样 通过 之 前 的 hexdump 来 读 取 表 
空间 文件 ， 从 数据 页 c000 开 始 查 看 : 





0000c000 67 ce fc Ob 00 00 00 03 ff ff ff ff ff ff ff 
0000c010 00 00 00 Oa 6a d9 cO 89 45 bf 00 00 00 00 00 
0000c020 00 00 00 00 OO c3 00 02 03 a7 80 03 00 00 00 
0000c030 00 80 00 05 OO 00 OO O1 00 OO 00 OO 00 00 00 
0000c040 00 00 00 00 OO 00 OO OO O1 a1 00 OO 00 c3 00 
0000c050 00 02 00 f2 00 OO 00 c3 00 00 00 02 00 32 O1 
0000c060 02 00 1d 69 Ge 66 69 6d 75 6d 00 02 00 Ob 00 
0000c070 73 75 70 72 65 6d 75 6d 14 c3 00 00 00 10 ff 
0000c080 00 00 00 b6 2b 00 00 00 00 51 4b 06 80 00 00 
0000c090 2d 01 10 61 61 61 61 61 61 61 61 61 61 61 61 61|-..aaaaaaaaaaaaa 
0000c0a0 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|aaaaaaaaaaaaaaaa 
0000cObO 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|aaaaaaaaaaaaaaaa 
0000cOcO 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|aaaaaaaaaaaaaaaa 
0000cO0dO 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|aaaaaaaaaaaaaaaa 
0000c0e0 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|aaaaaaaaaaaaaaaa 
0000cOfO 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|aaaaaaaaaaaaaaaa 
0000c100 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|aaaaaaaaaaaaaaaa 
0000c110 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|aaaaaaaaaaaaaaaa 





0000c390 61 61 61 00 00 00 c3 00 00 00 04 OO 00 00 26 00]|aaa........... &.| 
0000c3a0 00 00 00 00 00 fc fc 00 00 00 00 00 00 OO OO 00|................ 











可 以 看 到 ， CO 
VARCHAR (65532) 的 前 768 字 节 的 前 绥 i (prefix) 数据 (这 里 都 是 
a) ， 之 后 是 偏 移 量 ， 指 问 行 洲 出 页 ， 也 就 是 前 面 用 户 看 到 的 
Uncompressed BLOB Page。 因 此 ， 对 于 行 溢出 数据 ,J 其 存放 采用 图 4-4 
的 方式 。 








InnoDB fj 


prefix 768bytes 





BLOB Page 


图 4-4 (früh SUUS CER 


那 多 长 的 VARCHAR 是 保存 在 单个 数据 页 中 的 ， 从 多 长 开始 又 会 保 
存在 BLOB 页 昵 ? 可 以 这 样 进行 思考 : InnoDB 存 储 引 擎 表 是 索引 组 织 
的 ， 即 B+Tree 的 结构 ， 这 样 每 个 页 中 至 少 应 该 有 两 条 行 记 录 《和 否则 失去 
了 B+Tree 的 意义 ， 变 成 链表 了 ) 。 因 此 ， 如 果 页 中 只 能 存放 下 一 条 记 
Pe ee 擎 会 自动 将 行 数据 存放 到 溢出 页 中 。 考 虑 下 面 

一 种 情况 : 




















mysql>CREATE TALBE t( 

->a VARCHAR(9000) 

-> )ENGINE-InnoDB; 

Query OK,0 rows affected(0.13 sec) 
mysql>INSERT INTO t 

->SELECT REPEAT('a',9000); 

Query OK,1 row affected(0.04 sec) 
Records:1 Duplicates:0 Warnings:0 
mysql>INSERT INTO t 

->SELECT REPEAT('a', 9000); 

Query OK,1 row affected(0.04 sec) 
Records:1 Duplicates:0 Warnings:0 





表 {t 变 长 字段 列 a 的 长 度 为 9000， 故 能 存放 在 一 个 数据 中 ， 但 是 这 并 
不 能 保证 两 条 长 度 为 9000 的 记录 都 能 存放 在 一 个 页 中 。 知 此 时 通过 
py_innodb_page_info 工 具 查 看 ， 可 知行 数据 是 否 存 放 在 BLOB 页 中 。 














[rootünineyouO-43 mytest]#py_innodb_page_info.py-v t.ibd 
page offset 00000000, page type<File Space Header> 

page offset 00000001, page type<Insert Buffer Bitmap> 
page offset 00000002,page type<File Segment inode> 

page offset 00000003,page type<B-tree Node>,page level-c0000-— 
page offset 00000004, page type<Uncompressed BLOB Page> 
page offset 00000005,page type<Uncompressed BLOB Page> 
Total number of page:6: 

Insert Buffer Bitmap:1 

Uncompressed BLOB Page:2 

File Space Header:1 

B-tree Node:1 

File Segment inode:1 








注意 ”因为 py_innodb_page_info 工 具 查 看 的 是 磁盘 文件 ， 故 运行 上 
述 示例 时 ， 需 要 确 你 绥 冲 池 中 的 页 都 刷 回 到 磁盘 。 


但 是 ， 如 果 可 以 在 一 个 页 中 人 至少 放 入 两 行 数据 ， 那 VARCHAR 类 型 
的 行 数据 就 不 会 存放 到 BLOB 页 中 去 。 经 过 多 次 试验 测试 ， 发 现 这 个 国 
值 的 长 度 为 8098。 如 用 户 建 立 一 个 列 为 varchar (8098) 的 表 ， 然 后 插入 
2 条 记录 : 





mysql>CREATE TABLE t( 

->a varchar(8098) 

)ENGINE=INnoDB; 

Query OK,0 rows affected(0.12 sec) 
mysql>INSERT INTO t SELECT REPEAT('a',8098); 
Query OK,1 row affected(0.04 sec) 

Records:1 Duplicates:0 Warnings:0 
mysql>INSERT INTO t SELECT REPEAT('a', 8098); 
Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:0 








接着 用 py_innodb_page_info 工 具 对 表 空 间 t.ibd 进 行 查 看 ， 可 以 发 现 
此 时 的 行 记录 都 是 存放 在 数据 页 中 ， 而 不 是 在 BLOB 页 中 了 OR 
Microsoft SQL ”Server 数 据 库 的 DBA 可 能 会 感觉 InnoDB 存 储 引 擎 对 于 
VARCHAR 类 型 的 管理 和 SQL Server 中 的 varchar (MAX) 类似 ) 。 








[rootQünineyouO-43 mytest]#py_innodb_page_info.py-v t.ibd 
page offset 00000000,page type<File Space Header> 

page offset 00000001,page type<Insert Buffer Bitmap> 
page offset 00000002,page type<File Segment inode> 

page offset 00000003,page type<B-tree Node>,page level-c0000-— 
page offset 00000000,page type<Freshly Allocated Page> 
page offset 00000000,page type<Freshly Allocated Page> 
Total number of page:6: 

Freshly Allocated Page:2 

Insert Buffer Bitmap:1 

File Space Header:1 

B-tree Node:1 

File Segment inode:1 





另 一 个 问题 是 ， 对 于 TEXT 或 BLOB 的 数据 类 型 ， 用 户 总 是 以 为 它 
们 是 存放 在 Uncompressed BLOB Page 中 的 ， 其 实 这 也 是 不 准确 的 。 是 放 
在 数据 页 中 还 是 BLOB 页 中 ， 和 前 面 讨 论 的 VARCHAR 一 样 ， 至 少 保证 
一 个 页 能 存放 两 条 记录 ， 如 : 








mysql>CREATE TABLE t( 
->a BLOB 


- >)ENGINE=InnoDB; 

Query OK,0 rows affected(0.12 sec) 
mysql>INSERT INTO t SELECT REPEAT('a',8000); 
Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:0 
mysql>INSERT INTO t SELECT REPEAT('a', 8000); 
Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:0 
mysql>INSERT INTO t SELECT REPEAT('a', 8000); 
Query OK,1 row affected(0.01 sec) 

Records:1 Duplicates:0 Warnings:O 


mysql>INSERT INTO t SELECT REPEAT('a',8000); 
Query OK,1 row affected(0.06 sec) 
Records:1 Duplicates:0 Warnings:0 





上 述 例子 建立 含有 BLOB 类 型 列 的 表 ， 然 后 插入 4 行 数据 长 度 为 8000 
的 记录 。 若 通过 py_innodb_page_info 工 具 对 表 空 间 t.ibd 进 行 查看 ， 会 发 





现 其 实数 据 并 没有 保存 在 BLOB 页 中 。 





[rootQünineyouO-43 mytest]#py_innodb_page_info.py-v t.ibd 

page offset 00000000, page type<File Space Header> 

page offset 00000001, page type<Insert Buffer Bitmap> 

page offset 00000002,page type<File Segment inode> 

page offset 00000003, page type<B-tree Node>,page level<0001> 
page offset 00000004, page type<B-tree Node>,page level-c0000-— 
page offset 00000005,page type<B-tree Node>,page level-c0000-— 
page offset 00000006,page type<B-tree Node>,page level-c0000-— 
page offset 00000000,page type<Freshly Allocated Page> 

Total number of page:8: 

Freshly Allocated Page:1 

Insert Buffer Bitmap:1 

File Space Header:1 

B-tree Node:4 

File Segment inode:1 





当然 既然 用 户 使 用 了 BLOB 列 类 型 ， 一 般 不 可 能 存放 长 度 这 么 小 的 


数据 。 因 此 在 大 多 数 的 情况 下 BLOB 的 行 数 据 还 是 会 发 生 行 溢 
数据 保存 在 BLOB 页 中 ， 数 据 页 只 保存 数据 的 前 768 字 节 。 





4.3.4 ”Compressed 和 Dynamic 行 记录 格式 


InnoDB 1.0.x 版 本 开始 引入 了 新 的 文件 格式 (file format， 用 户 可 以 
理解 为 新 的 页 格式 ) ， 以 前 支持 的 Compact 和 Redundant 格 式 称 为 
Antelope 文 件 格式 ， 新 的 文件 格式 称 为 Barracuda 文 件 格 式 。Barracuda 文 
件 格式 下 拥有 两 种 新 的 行 记录 格式 : Compressed 和 Dynamic。 


新 的 两 种 记录 格式 对 于 存放 在 BLOB 中 的 数据 采用 了 完全 的 行 溢出 
的 方式 ， 如 图 4-5 所 示 ， 在 数据 页 中 只 存放 20 个 字 市 的 指针 ， 实 际 的 数 
据 都 存放 在 Off Page 中 ， 而 之 前 的 Compact 和 Redundant 两 种 格式 会 存放 
768 个 前 级 字 节 。 





InnoDB 行 
NES 


Off Page 


图 4-5 Barracuda 文 件 格式 的 溢出 行 


Compressed 行 记录 格式 的 另 一 个 功能 就 是 ， 存 储 在 其 中 的 行 数据 会 
以 zlib 的 算法 进行 压缩 ， 因 此 对 于 BLOB、TEXT、VARCHAR 这 类 大 长 
度 类 型 的 数据 能 够 进行 非常 有 效 的 存储 。 





43.5 CHAR 的 行 结构 存储 


通常 理解 VARCHAR 是 存储 变 长 长 度 的 字符 类 型 ，CHAR 是 存储 回 
定 长 度 的 字符 类 型 。 而 在 前 面 的 小 节 中 ， 用 户 已 经 了 解 行 结构 的 内 部 的 
并 可 以 发 现 每 行 的 变 长 字段 长 度 的 列表 都 没有 存储 CHAR 类 型 的 


然而 ， 值 得 注意 的 是 之 前 给 出 的 两 个 例子 中 的 字符 集 都 是 单字 节 的 
latin1 格 式 。 从 MySQL 4.1 版 本 开始 ，CHR N) 中 的 N 指 的 是 字符 的 长 
度 ， 而 不 是 之 前 版 本 的 字 节 长 度 。 也 就 说 在 不 同 的 字符 集 下 ，CHAR 类 
型 列 内 部 存储 的 可 能 不 是 定 长 的 数据 。 例 如 下 面 的 这 个 示例 : 














mysql>CREATE TABLE j( 

->a CHAR(2) 

->)CHARSET=GBK ENGINE=InnoDB; 
Query OK,0 rows affected(0.11 sec) 
mysql>INSERT INTO j SELECT'ab'; 
Query OK,1 row affected(0.03 sec) 
Records:1 Duplicates:0 Warnings:0 
mysql>SET NAMES GBK; 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO j SELECT' 我 们 ' 
Query OK,1 row affected(0.04 sec) 
Records:1 Duplicates:0 Warnings:O 
mysql>INSERT INTO j SELECT'a' 
Query OK,1 row affected(0.03 sec) 
Records:1 Duplicates:0 Warnings:O 





在 上 述 例子 中 ， 表 j 的 字符 集 是 GBK。 用 户 分 别 插入 了 两 个 字符 的 
数据 'ab' 和 ' 我 们 '， 然 后 查看 所 占 字 节 ， 可 得 如 下 结 





mysql>SELECT a,CHAR LENGTH(a), LENGTH(a) 
E 


->FROM j\G 


FOR IIIS TOI ICICI IOI I IOI I IO I d. POW 2G II ICICI II IIIA Ok 
a:ab 

CHAR. LENGTH(a) :2 

LENGTH(a) :2 

FOI IOI ITO EE E E ITO TO III I 2. FOW RGGI I IOI III CII AOR 
a: 我 们 

CHAR_LENGTH(a):2 

LENGTH(a):4 

e Fe He de e OR Je Se Ye E e e Se E E e He He Fe He e VE He He He E BROW SEER E 


aia 

CHAR LENGTH(a):1 
LENGTH(a):1 

3 rows in set(0.00 sec) 








通过 不 同 的 CHAR_LENGTH 和 CHAR 函 数 可 以 观察 到 : 前 两 个 记 
录 'ab' 和 ' 我 们 ' 字 符 串 的 长 度 都 是 2。 但 是 内 部 存储 上 'ab' 占 用 2 字 节 ， 而 ' 我 
们 ' 占 用 4 字 节 。 如 果 通 过 HEX 函 数 查 看 内 部 十 六 进 制 的 存储 ， 可 以 看 
到 : 





mysql>SELECT a,HEX(a) 


->FROM j\G; 


Ex E CK OER EK ER EROR 1L POME OOHRRRARARHGOOOOOOO OX EG 

HEX(a) :6162 

SEX YE KEOOOO ER ERO ORE FEDERER 2.rQu**eeHheeeeeeeeeeeeeeee 
们 

HEX(a) : CED2C3C7 

WOCHE KA ODIO TERRE RERE ERE EE d. Qu OOHRRRRARAJUOOHOORR X A 


a:a 
HEX(a):61 
3 rows in set(0.00 sec) 





可 以 看 到 对 于 字符 串 'ab'， 其 内 部 存储 为 0x6162。 而 字符 串 ' 我 们 "为 
0xCED2C3C7。 因 此 对 于 多 字 节 的 字符 编码 ，CHAR 类 型 不 再 代表 固定 
长 度 的 字符 串 了 。 例 如 ， 对 于 UTF-8 下 CHAR (10) 类 型 的 列 ， 其 最 小 
可 以 存储 10 字 节 的 字符 ， 而 最 大 可 以 存储 30 字 节 的 字符 。 因 此 ， uA 
字 节 字符 编码 的 CHAR 数 据 类 型 的 存储 ，InnoDB 存 储 引擎 在 内 部 将 其 
为 变 长 字符 类 型 。 这 也 就 意味 着 在 变 长 长 度 列表 中 会 de nr 
型 的 长 度 。 下 面 通过 hexdump 工 具 来 查看 表 空 间 j.ibd 文 件 : 























0000c080 00 00 b6 2b 2b 00 00 00 51 52 da 80 00 00 00 2d|...++... QR..... 

0000c090 01 10 61 62 04 00 00 00 18 ff d5 00 00 00 b6 ont ab E REL +| 
0000c0a0 2c 00 00 00 51 52 db 80 00 00 00 2d 01 10 ce d2|,...QR..... Teal 
0000cObO c3 c7 00 00 00 00 00 00 00 00 00 00 00 OO OO 00|................ 





整理 后 可 以 得 到 如 下 结果 : 





# 第 一 行 记录 

02/* Mp 将 CHAR 视 作 变 长 类 型 */ 
00/ *NULL E 

00 00 10 00 ru E RET een / 
00 00 00 b6 2b 2b/*Row 

00 00 00 51 52 dolere ton 
80 00 00 00 2d 01 10/*Roll Point*/ 
61 62/* 字 符 'ab'*/ 

# 第 二 行 记录 

94/* 变 长 字段 1 ne 将 CHAR 视 作 变 长 类 型 */ 
990/*NULL 标 志 位 */ 

00 00 18 ff d5/* Recoder Header*/ 
00 00 00 b6 2b 2c/*RowID*/ 

00 00 00 51 52 db/*TransactionID*/ 
80 00 00 00 2d 01 10/*Roll Point*/ 
c3 d2 c3_c7/* 字 符 ' 我 们 '*/ 

# 第 三 行 记录 

92/* 变 长 字段 1 (e 将 CHAR 视 作 变 长 类 型 */ 
690/*NULL 标 志 

00 00 20 ff oe i ed PORE / 
00 00 00 b6 2b 2d/*Row 

00 00 00 51 53 49 erence eich toed 
80 00 00 00 2d 01 10/*Roll Point*/ 
61 20/* 字 符 'a'*/ 





上 述 例子 清楚 地 显示 了 InnoDB 存 储 引 擎 内 部 对 CHAR 类 型 在 多 字 节 
字符 集 类 型 的 存储 。CHAR 类 型 被 明确 视 为 了 变 长 字符 类 型 ， 对 于 未 能 
占 满 长 度 的 字符 还 是 填充 0x20。InnoDB 存 储 引 擎 内 部 对 字符 的 存储 和 
我 们 用 HEX 函 数 看 到 的 也 是 一 致 的 。 因 此 可 以 认为 在 多 字 节 字符 集 的 情 
况 下 ，CHAR 和 VARCHAR 的 实际 行 存储 基本 是 没有 区 别 的 。 














4.4 InnoDB 数 据 页 结构 


相信 通过 前 面 几 个 小 节 的 介绍 ， 读 者 已 经 知道 页 是 InnoDB 存 储 引 
擎 管理 数据 库 的 最 小 磁盘 单位 。 页 类 型 为 B-tree Node 的 页 存放 的 即 是 表 
中 行 的 实际 数据 了 。 在 这 一 节 中 ， 我 们 将 从 底层 具体 地 介绍 InnoDB 数 
所 页 的 内 部 存储 结构 。 


注意 ”InnoDB 公 司 本 身 并 没有 详细 介绍 其 页 结构 的 实现 ，MySQL 
的 官方 手册 中 也 基本 没有 提 及 InnoDB 存 储 引 擎 页 的 内 部 结构 。 本 节 通 
过 阅读 源 代 码 来 了 解 InnoDB 的 页 结构 ， 此 外 结合 了 Peter 对 于 InnoDB 页 
结构 的 分 析 。Peter 写 这 部 分 内 容 的 时 间 很 久远 了 ， 在 其 之 后 InnoDB 引 
入 了 Compact 格 式 ， 页 结构 已 经 有 所 改动 ， 因 此 可 能 出 现 对 页 结构 分 析 
错误 的 情况 ， 如 有 错误 ， 和 希望 可 以 指出 。 


InnoDB 数 据 页 由 以 下 7 个 部 分 组 成 ， 如 图 4-6 所 示 。 
口 File Header 〈 文 件 头 ) 





DPage Header (H$) 

DInfimnun 和 Supremum Records 

口 User Records (HP wx, MWWK) 
Q Free Space (23/5) 22/4] ) 

U Page Directory (页 目录 ) 


口 File Trailer 〈 文 件 结尾 信息 ) 


File Header | 3835 
Page Header —— 56 字 节 


Infimun + Records 


行 记录 
Page Size 


Free EL 


mE" Directory 


File Trailer | EA 





图 4-6 InnoDB 存 储 引 擎 数据 页 结构 


其 中 File Header. Page Header. File Trailer 的 大 小 是 固定 的 ， 分 别 
为 38、56、8 字 节 ， 这 些 空间 用 来 标记 该 页 的 一 些 信 息 ， 如 Checksum， 
数据 页 所 在 B+ 树 索引 的 层 数 等 。User ^ Records. Free ^ Space. Page 
Directory 这 些 部 分 为 实际 的 行 记录 存储 空间 ， 因 此 大 小 是 动态 的 。 在 接 
下 来 的 各 小 节 中 将 具体 分 析 各 组 成 部 分 。 


4.4.1 File Header 


File Header 用 来 记录 页 的 一 些 头 信息 ， 由 表 4-3 中 8 个 部 分 组 成 ， 共 
占用 38 字 节 。 











#43 File Header 组 成 部 分 
kom" 

MySQL MySQULLH ZR, DS 0 ES MySQL 
MA, WRAT checksum 但 (一 种 新 的 checksum f) 
RIA RA. UO] ai AY KA LGB, WERN 
大 小 为 1KB， 那 和 总 其 有 (65536 个 页 FIL PAGE OFFSET To UE 
PEERS ID 为 0， 那么 搜 索 责 (10，1) WERE 
ic TES 
FIL PAGE PREV | — 4 — | RR IG Be Tree lu CET Eu AU RU 
FIL PAGE NEXT | = 4 — | EDU Po B+ Tree o TT PUR 
FIL PAGE LSN VA UR MULAN EL REPE LSN (Log Sequence Number) 
InnoDB (£424 R AA, AMARLA 4, IE OMSBR, HEE 
Ge PERO. 好 实 际 行 记 录 的 在 全 空间 
WARE RU Rr o OC POE T LN 
fi. APIS, HERNO 


名 R o MG 
FIL PAGE SPACE. 
OR CHKSUM 


=+ 


a 


FIL PAGE OFFSET] — 4 


PL PAGE TYPE | 2 


FIL PAGE FILE. 
FLUSH LSN 


FIL PAGE ARCH. 
L0G NO OR SPACE} 4 | 从 MOSQL41 开 始 TCE T CHI 
D 


ae 


à i 
FIL PAGE INDEX 
FIL PAGE UNDO LOG 
FIL PAGE NODE 
TI. AGE IUE FREE LIST 
FL AGE TYPE ALLOCATED 
FL AGE IUE BID 
FL PAGE TYPE SYS 
FIL PAGE TYPE TRX SYS 
TIL PAGE TYPE FSP HDR 
FIL PAGE TYPE XDES 
FIL PAGE TYPE BLOB 


MB ER eh ae 


FARA 
(BT 


= 3 
let Bufer (if 
M 
IDEO 
fil = Header 


BLOB i 


4.4.2 Page Header 


接着 File Header 部 分 的 是 Page Header， 该 部 分 用 来 记录 数据 页 的 状 
态 信息 ， 由 14 个 部 分 组 成 ， 共 占用 56 字 节 ， 如 表 4-5 所 示 。 





#45 Page Header 组 成 部 分 
说 H 


fE Page Directory ( 页 目录 ) 中 的 Slot CR) 数 “44S Page 


Directory” MERANA 


PAGE HEAP TOP 2 0| Ne ORE E AB AER 


名 称 XM 


- 


PAGE N DIR SLOTS 


人 一 > 


PAGE N HEAP 的 中 的 记录 数 。 一 共 占用 22, UR 15 位 表示 行 记 录 格 式 
PAGE FREE 指 亲 可 重用 空间 的 首 指针 
PAGE GARBAGE 2 | EBORE AG TIGRE delete fag 为 LIBRA 


PAGE LAST INSERT ) | eH ACRE 

最 后 插入 的 方向 ， 可 能 的 取 但 为 
O PAGE LEFT (0x01) 

O PAGE RIGHT (0x02) 

O PAGE SAME REC (0x03) 

O PAGE SAME PAGE (0x04) 

O PAGE NO DIRECTION (0x05) 


PAGE N DIRECTION ) | SMES ILRI CR 


PAGE DIRECTION ) 


PAGE N RECS VU RACE 

PAGE MAX TRX 1D Vict RU ROS ID, REREN <= Index fJ 
PAGE LEVEL 2 | atate eto, uo TRIM HE, UME ELEM OE 
PAGE INDEX 1D Ril ID, SU REA T c 


i Ht 


PAGE BTR SEG LEA 


PAGE BTR SEG TO 


I) 


) 





BRE Te BEAN sement header, HEFCE BY 
A Roo UA 

Be HRUE TAE ECH segment header, ERAI E B WE Rat 
jt 


4.4.3 Infimnum 和 Supremum Record 


在 InnoDB 存 储 引 擎 中， 每 个 数据 页 中 有 两 个 虚拟 的 行 记 录 ， 用 来 
限定 记录 的 边界 。Infimum 记 录 是 比 该 页 中 任何 主键 值 都 要 小 的 值 ， 
Supremum 指 比 任何 可 能 大 的 值 还 要 大 的 值 。 这 两 个 值 在 页 创建 时 被 建 
立 ， 并 且 在 任何 情况 下 不 会 被 删除 。 在 Compact 行 格式 和 Redundant 行 格 
式 下 ， 两 者 占用 的 字 节 数 各 不 相同 。 网 4-7 显 示 了 Infimum 和 Supremum 
记录 。 
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图 4-7 InfinumfllSupremum Record 


x 


4.4.4 User Record 和 Free Space 


User Record 就 是 之 前 讨论 过 的 部 分 ， 即 实际 存储 行 记 录 的 内 容 。 再 
次 强调 ，ImnoDB 存 储 引 擎 表 总 是 B+ 树 索引 组 织 的 。 


Free Space 很 明显 指 的 就 是 空 亲 空间， 同样 也 是 个 链表 数据 结构 。 
在 一 条 记录 被 删除 后 ， 该 空间 会 被 加 入 到 空闲 链表 中 。 








4.4.5 Page Directory 


Page Directory (HAS) 中 存放 了 记录 的 相对 位 置 〈 注 意 ， 这 里 存 
放 的 是 页 相对 位 置 ， 而 不 是 偏 移 量 ) ， 有 些 时 候 这 些 记 录 指 针 称 为 
Slots Œ) BK A aet# (Directory Slots) 。 与 其 他 数据 库 系 统 不 同 的 是 ， 
在 InnoDB 中 并 不 是 每 个 记录 拥有 一 个 槽 ，InnoDB 存 储 引 擎 的 槽 是 一 个 
稀疏 目录 (sparse directory) ， 即 一 个 槽 中 可 能 包含 多 个 记录 。 伪 记录 
Ifimnum 的 n_owned 值 总 是 为 1， 记 录 Supremum 的 n_owned 的 取 值 范围 为 
[1，8]， 其 他 用 户 记 录 n_owned 的 取 值 范围 为 [4，8]。 当 记录 被 插 入 或 删 
除 时 需要 对 槽 进行 分 裂 或 平衡 的 维护 操作 。 


在 Slots 中 记录 按照 索引 键 值 顺序 存放 ， 这 样 可 以 利用 二 又 查找 迅速 
找到 记录 的 指针 。 假 设 有 
Py, Ry va) ， 同 时 假设 一 个 村 











CT, 'd', Ts ‘b's 'e', 'g', he 'h', i 9 
中 包含 4 条 记录 ， 则 Slots 中 的 记录 可 能 是 Ca» 'e, i. 


由 于 在 InnoDB 存 储 引 擎 中 Page “Direcotry 是 稀 朴 目录 ， 二 又 查找 的 
结果 只 是 一 个 粗略 的 结果 ， 因 此 InnoDB 存 储 引 擎 必须 通过 recorder 
header 中 的 next_record 来 继续 得 找 相 关 记 录 。 同 时 ，Page Directory 很 好 
地 解释 J recorder header 中 的 n_owned 值 的 含义 ， 因 为 这 些 记 录 并 不 包括 
在 Page Directory 中 。 


需要 牢记 的 是 ，B+ 树 索引 本 号 并 不 能 找到 具体 的 一 条 记录 ， 能 找 
到 只 是 该 记录 所 在 的 页 。 数 据 库 把 页 载 入 到 内 存 ， 然 后 通过 Page 
Directory 再 进行 二 又 碍 找 。 只 不 过 二 又 查找 的 时 间 复 杂 度 很 低 ， 同 时 在 
内 存 中 的 查找 很 快 ， 因 此 通常 忽略 这 部 分 但 找 所 用 的 时 间 。 











4.4.6 File Trailer 


为 了 检测 页 是 否 已 经 完整 地 写 入 磁盘 〈 如 可 能 发 生 的 写 入 过 程 中 磁 
盘 损 坏 、 机 器 关机 等 ) ，InnoDB 存 储 引 擎 的 页 中 设置 了 File Trailer 部 


Fe 





File Trailer 只 有 一 个 FHIL_PAGE_END_LSN 部 分 ， 占 用 8 字 节 。 前 4 字 
节 代 表 该 页 的 checksum 值 ， 最 后 4 字 节 和 File Header 中 的 FIL_PAGE_LSN 
相同 。 将 这 两 个 值 与 File Header 中 的 FIL_PAGE_SPACE_OR_CHKSUM 
和 FIL_PAGE_LSN 值 进行 比较 ， 看 是 否 一 致 〈checksum 的 比较 需要 通过 
InnoDB 的 checksum 函 数 来 进行 比较 ， 不 是 简单 的 等 值 比较 ) ， 以 此 来 
保证 页 的 完整 性 (not corrupted) 。 


在 默认 配置 下，InnoDB 存 储 引 擎 每 次 从 磁盘 读 取 一 个 页 束 会 检测 
该 页 的 完整 性 ， 即 页 是 否 发 生 Corrupt， 这 束 是 通过 File Trailer 部 分 进行 
检测 ， 而 该 部 分 的 检测 会 有 一 定 的 开销 。 用 户 可 以 通过 参数 
innodb_checksums 来 开启 或 关闭 对 这 个 页 完整 性 的 检查 。 


MySQL 5.6.6 版 本 开始 新 增 了 参数 innodb_checksum_algorithm， 访 参 
数 用 来 控制 检测 checksum 函 数 的 算法 ， 默 认 值 为 crc32， 可 设置 的 值 


A: innodb. crc32. none, strict innodb、strict_crc32、strict_none。 

















innodb 为 兼容 之 前 版 本 ImnnoDB 页 的 checksum 检 测 方式 ，crc32 为 
MySQL ”5.6.6 版 本 引进 的 新 的 checksum 算 法 ， 该 算法 较 之 前 的 innodb 有 
着 较 高 的 性 能 。 但 是 若 表 中 所 有 页 的 checksum 值 都 以 strict 算 法 保存 ， 那 
么 低 版 本 的 MySQL 数 据 库 将 不 能 读 取 这 些 页 。none 表 示 不 对 页 启用 
checksum 检 查 。 


strict_* 正 如 其 名 ， 表 示 严 格 地 按照 设置 的 checksum 算 法 进行 页 的 检 
测 。 因 此 车 低 版 本 MySQL 数 据 库 升 级 到 MySQL 5.6.6 或 之 后 的 版 本 ， 启 
用 strict_crc32 将 导致 不 能 读 取 表 中 的 页 。 启 用 strict_crc32 方 式 是 最 快 的 
方式 ， 因 为 其 不 再 对 innodb 和 crc32 算 法 进行 两 次 检测 。 故 推荐 使 用 该 设 
置 。 磊 数据库 从 低 版 本 升级 而 来 ， 则 需要 进行 mysqlL_upgrade 操 作 。 


44.7 ”InnoDB 数 据 页 结构 示例 分 析 


通过 前 面 各 小 市 的 介绍 ， 相 信 读 者 对 pups dile 3E 的 数据 页 已 
经 有 了 一 个 大 致 的 了 解 。 本 小 节 将 通过 一 个 具体 的 表 ， 结 合 前 面 小 节 所 
介绍 的 内 容 来 具体 分 析 一 个 数据 页 的 内 部 存储 结构 。 首 先 建立 一 张 表 
并 导入 一 定量 的 数据 : 





mysql>DROP TABLE IF EXISTS t; 
Query OK,0 rows affected(0.04 sec) 
mysql>CREATE TABLE t( 
->a INT UNSIGNED NOT NULL AUTO INCREMENT, 
->b CHAR(10), 
->PRIMARY KEY(a), 
->)ENGINE=InnoDB CHARSET=UTF8; 
Query OK,0 rows affected(0.00 Sec) 
mysql DEÉLIMITERS$$ 
mysql-— CREATE PROCEDURE load t(count INT UNSIGNED) 
- >BEGIN 
- >SET@c=0; 
->WHILE@c<count DO 
->INSERT INTO t 
->SELECT NULL, REPEAT(CHAR(97+RAND()*26),10); 
- >SET@c=@c+1; 
->END WHILE; 
->END; 
->$$ 
Query OK,0 rows affected(0.00 sec) 
mysql-DELIMITER; 
mysql>CALL load t(100); 
Query OK,0 rows affected(0.60 sec) 
mysql>SELECTa, bFROM t LIMIT 10; 


|1|dddddddddd| 
|2| hhhhhhhhhh | 
|3 | bbbbbbbbbb | 
|4]iiiiiiiiii 

|5|nnnnnnnnnn| 
16 | qqqqqqqqagq| 
|7| 0000000000 | 
l8lyyyyyyyyyyl 
19lyyyyyyyyyy | 
Lesbia deii 





10 rows in set(0.00 is 





接着 用 工具 py_innodb_page_info 来 分 析 t.ibd， 得 到 如 下 内 容 : 





[rootünineyouO-43 mytest]#py_innodb_page_info.py-v t.ibd 
page offset 00000000,page type<File Space Header> 

page offset 00000001, page type<Insert Buffer Bitmap> 
page offset 00000002,page type<File Segment inode> 

page offset 00000003,page type<B-tree Node>,page level-c0000-— 
page offset 00000000,page type<Freshly Allocated Page> 
page offset 00000000,page type<Freshly Allocated Page> 
Total number of page:6: 

Freshly Allocated Page:2 

Insert Buffer Bitmap:1 

File Space Header:1 

B-tree Node:1 

File Segment inode:1 





可 以 发 现 第 四 个 页 (page offset 3) 是 数据 页 ， 然 后 通过 hexdump 来 
分 析 tibd 文 件 ， 打 开 整 理 得 到 的 十 六 进 制 文件 ， 数 据 页 从 
0x0000c000 (16K*3=0xc000) 处 开始 ， 得 到 以 下 内 容 : 


0000c000 
0000c010 
0000c020 
0000c030 
0000c040 
0000c050 
0000c060 
0000c070 
0000c080 
0000c090 
0000c0a0 
0000c0b0 
0000c0c0 
0000c0d0 
0000c0e0 
0000cgf9 
0000c100 
0000c110 
0000c120 
0000c130 
0000c140 
0000c150 
0000c160 
0000c170 
0000c180 
0000c190 
0000c1a0 
0000c1b0 
0000c1c0 
0000c1d0 
0000c1e0 
0000c1f0 


0000ffco 
06000ffd6 
e000f fed 
oooofffO 








' kkkkkkkkkk. 
Pa" ORAT am 
PEE Dioie:.:i) 0 
Uu... 06... U...E 
[ND NIRE H 

.m...c..]9j. 








45K ^) NT AU Il File Header 的 38 字 节 : 


152 1b 24 00， 数 据 页 的 Checksum 值 。 


LI00 00 00 03, 


Off ff ff ff, 前 一 个 页 ， 因 为 只 有 当 
Oxffffffff。 


页 的 侦 移 量 ， 从 0 开始 。 


Off ff ff ff, h—4 


Oxffffffff. 
L100 00 00 0a 6a e0 ac 93, 


O45 bf, H 


A 





HU 


SI^ 247 


个 数据 页 ， 所 以 这 





， 因 为 只 


有 


= 


页 的 LSN。 


类 型 ，0x45bf 代 表 数 据 页 。 
这 里 暂时 不 管 该 


L100 00 00 00 00 00 00, 


L100 00 00 dc, KE 


不 急 着 看 下 面 的 Page Header 部 分 ， 


x 间 的 SPACE ID. 


FER 


HU 


个 数据 页 ， 所 以 这 


值 。 


观察 File Trailer 部 分 


里 为 


里 为 


File Trailer 通 过 比较 File Header 部 分 来 保证 页 写 入 的 完整 性 。File Trailer 
We A: 





95 ae 5d 39 6a e0 ac 93 





L995 ae 5d 39, Checksum/{H, iZí[HilitchecksumrA 20-9 File Header 
部 分 的 checksum 值 进行 比较 。 


O6a e0 ac 93， 注 意 该 值 和 File Header 部 分 页 的 LSN 后 4 个 值 相 等 。 


接着 分 析 56 字 节 的 Page Header 部 分 。 对 于 数据 页 而 言 ，Page Header 
部 分 保存 了 该 页 中 行 记录 的 大 量 细节 信息 。 分 析 后 可 得 : 











Page Header(56 bytes): 

PAGE N DIR SLOTS-0x001a 

PAGE HEAP TOP-0x0dcO 

PAGE N HEAP-0x8066 

PAGE FREE-0x0000 

PAGE GARBAGE-0x0000 

PAGE LAST INSERT-0x0da5 

PAGE DIRECTION-0x0002 

PAGE N DIRECTION-0x0063 

PAGE N RECS-0x0064 

PAGE MAX TRX ID-0x0000000000000000 
PAGE LEVEL-00 00 

PAGE INDEX ID-0x00000000000001ba 
PAGE BTR SEG LEAF-0x000000dc00000002900f2 


PAGE BTR SEG TOP-0x000000dc000000020032 





PAGE N DIR SLOTS-0x001a, fVXPage Directory 264-18, 4E 
槽 占用 2 字 节 ， 我 们 可 以 从 0x0000ffc4 到 0x0000fff7 中 找到 如 下 内 容 : 





O0000ffcO O00 00 00 00 OO 70 Od 1d Oc 95 Oc Od Ob 85 Oa fd|..... 和 
0000ffdO Oa 75 09 ed 09 65 08 dd 08 55 07 cd 07 45 06 bd|.u...e...U...E. 

0000ffe0 06 35 05 ad 05 25 04 9d 04 15 03 8d 03 05 02 7d|.5...96......... y 
0000fffO 01 f5 01 6d 00 e5 00 63 95 ae 5d 39 6a eg ac 93|...m...c..]9j...| 





PAGE_HEAP_TOP=0x0dc0 代 表 空闲 空间 开始 位 置 的 偏 移 量 ， 即 
0xc000+0x0dc0=0xcdc0 处 开始 ， 观 察 这 个 位 置 的 情况 ， 可 以 发 现 这 的 确 
是 最 后 一 行 的 结束 ， 接 下 去 的 部 分 都 是 空 采 空间 了 。 








6000cdbO 00 00 00 2d 91 10 70 70 70 70 70 70 70 70 70 70|...-..pppppppppp| 
0000cdcO 00 00 00 00 00 00 00 OO 00 OO 00 OO OO OO OO 00|................ 
6000cddO 00 00 00 00 00 OO BO OO 00 00 OO OO 00 OO OO 00|................ 
0000cde0 00 00 00 00 00 00 00 OO GO OO OO OO OO OO OO 00|................ 





PAGE_N_HEAP=0x8066， 当 行 记 录 格 式 为 Compact 时 ， 初 始 值 为 
0x0802; 当 行 格式 为 Redundant 时 ， 初 始 值 是 2。 其 实 这 些 值 表 示 页 初始 


时 就 已 经 有 Infinimun 和 Supremum 的 伪 记 录 行 ，0x8066-0x8002=0x64， 
代表 该 页 中 实际 的 记录 有 100 条 记录 。 


PAGE_FREE=0x0000 代 表 可 重用 的 空间 首 地 址 ， 因 为 这 里 没有 进行 
过 任何 删除 操作 ， 故 这 里 的 值 为 0。 


PAGE_GARBAGE=0x0000 代 表 删 除 的 记录 字 节 为 0， 同 样 因 为 我 们 
没有 进行 过 删除 操作 ， 这 里 的 值 依然 为 0。 


PAGE_LAST_INSERT=0x0da5， 表 示 页 最 后 插入 的 位 置 的 偏 移 量 ， 
即 最 后 的 插入 位 置 应 该 在 0xc0000+0x0da5=0xcda5， 查 看 该 位 置 : 














0000cda0 00 03 28 f2 cb 00 00 00 64 00 00 OO 51 6e 4e 80|..(... .QnN 
6000cdbO 00 00 00 2d 01 10 70 70 70 70 70 70 70 70 70 E Ns cse 
0000cdcO 00 00 00 00 00 00 00 OO 00 OO OO OO 00 OO OO 00|................ 





可 以 看 到 的 确 是 最 后 插入 a 列 值 为 100 的 行 记录 ， 但 是 这 次 直接 指 问 
了 行 记 录 的 内 容 ， 而 不 是 指 风行 记录 的 变 长 字段 长 度 的 列表 位 置 。 


PAGE_DIRECTION=0x0002， 因 为 通过 自 增 长 的 方式 进行 行 记 录 的 
插入 ， 所 以 PAGE_DIRECTION 的 方向 是 向 右 ， 为 0x00002。 


PAGE_N_DIRECTION=0x0063， 表 示 一 个 方向 连续 插入 记录 的 数 
量 ， 因 为 我 们 是 上 自 增 长 的 方式 插入 了 100 条 记录 ， 因 此 该 值 为 99。 


PAGE_N_RECS=0x0064， 表 示 该 页 的 行 记 录 数 为 100， 注 意 该 值 与 
PAGE N _HEAP 的 比较 ，PAGE _N_HEAP 包 含 两 个 伪 行 记录 ， 并 且 是 通 
过 有 符号 的 方式 记录 的 ， 因 此 值 为 0x8066 。 


PAGE_LEVEL=0x00， 人 代表 该 页 为 叶子 节点 。 因 为 数据 量 目前 较 
， 因 此 当前 B+ 树 索引 只 有 一 层 。B+ 数 叶子 层 总 是 为 0x00。 


PAGE _INDEX_ID=0x00000000000001ba， 索 引 ID。 
上 面 束 是 数据 页 的 Page Header 部 分 了 ， 接 下 去 就 是 存放 的 行 记录 


， 前 面 提 到 过 InnoDB 存 储 引 擎 有 两 个 伪 记 录 ， 用 来 限定 行 记录 的 边 
接着 往 下 看 : 











UU 











0000c050 00 02 00 f2 00 OO 00 dc 00 00 00 02 00 32 01 00|............. 2..| 
0000c060 02 00 1c 69 6e 66 69 6d 75 6d 00 05 00 Ob 00 00|...infimum...... | 


0000c070 73 75 70 72 65 6d 75 6d Oa 00 00 00 10 00 22 00|supremum...... Mel 





观察 0xc05E 到 0xc077， 这 里 存放 的 就 是 这 两 个 伪 行 记录 ， 在 
InnoDB 存 储 引擎 中 设置 伪 行 只 有 一 个 列 ， 且 类 型 是 Char (80 。 伪 行 记 
录 的 读 取 方 式 和 一 般 的 行 记录 并 无 不 同 ， 我 们 整理 后 可 以 得 到 如 下 结 
果 : 








#InNfimum 伪 行 记录 
01 00 02 00 1c/*recorder header 
69 6e 66 69 73 75 6d 00/* AA THM OME IESE, 记录 内 容 就 是 Infimum (多 了 一 个 





/*0x00F 15) * 

ae ii eae 

05 00 Ob 00 00/*recorder header* 

73 75 70 72 65 6d 75 6d/* 只 有 UTR 记录 内 容 就 是 Supremum*/ 














然后 来 分 析 infimum 行 记录 的 recorder header 部 分 ， 最 后 两 个 字 节 位 
00 lc 表示 下 一 个 记录 的 位 置 的 偏 移 量 ， 即 当前 行 记录 内 容 的 位 置 
0xc063+0x001c， 即 0xc07f。0xc07f 应 该 很 熟悉 了， 之 前 分 析 的 行 记录 结 
构 都 是 从 这 个 位 置 开始 ， 如 : 








0000c070 73 75 70 72 65 6d 75 6d 0a 00 00 00 10 00 22 Pe dM YI mel 
0000c080 00 00 01 00 00 00 51 6d eb 80 00 00 00 2d 01 10|......Qm..... -..| 








s 以 看 到 这 就 是 第 一 条 实际 行 记 录 内 容 的 位 置 了 ， 整 理 后 我 们 可 以 
得 到 : 





/* 第 一 条 行 记录 */ 

00 00 00 91/* PARTER A den 这 里 的 ROWID 即 为 列 a 的 值 1*/ 
00 00 00 51 6d eb/*Transaction ID 

80 00 00 00 2d 01 10/*Roll Pointer 

64 64 64 64 64 64 64 64 64 64/* Dalit aaaaaaaaaa'*/ 





KMAR FS BY AE E: 





mysql>SELECT a,b,hex(b)FROM t ORDER BY a LIMIT 1; 
+- - -+ 


row in set(0. P sec) 














通过 Recorder Headerl']ZgJ& PAP ISA P— 4T ix BJ Ja Ee ER SUL 
可 以 得 到 该 页 中 所 有 的 行 记 录 ， 通 过 Page Header 的 PAGE_PREV 和 
PAGE_NEXT 束 可 以 知道 上 个 页 和 下 个 页 的 位 置 ， 这 样 InnoDB 存 储 引擎 








就 能 读 到 整 张 表 所 有 的 行 记 录 数 据 。 


最 后 分 析 Page Directory。 前 面 已 经 提 到 了 从 0x0000ffc4 到 0x0000fff7 
是 当前 页 的 Page Directory， 如 下 : 





O0000ffcO 00 00 00 00 OO 70 Od 1d Oc 95 Oc Od Ob 85 Oa fd|..... ER ERER S 
0000ffdO Oa 75 09 ed 09 65 08 dd 08 55 07 cd 07 45 06 bd|.u...e...U...E..] 
0000ffe0 06 35 05 ad 05 25 04 9d 04 15 03 8d 03 05 02 7d|.5...96......... y 


0000fffO 01 f5 01 6d 00 e5 00 63 95 ae 5d 39 6a eg ac 93|...m...c..]9j...] 





需要 注意 的 是 ，Page Directory 是 逆序 存放 的 ， 每 个 槽 占 2 字 节 ， 
此 可 以 看 到 00 63 是 最 初 行 的 相对 位 置 ， 即 0xc063; 00 70 束 是 最 后 一 行 
记录 的 相对 位 置 ， 即 0xc070。 我 们 发 现 这 就 是 前 面 分 析 的 Infimum 和 
Supremum 的 伪 行 记录 。Page Directory 模 中 的 数据 都 是 按照 主键 的 顺序 
存放 的 ， 因 此 查询 具体 记录 就 需要 通过 部 分 进行 。 前面 已 经 提 到 
InnoDB 存 储 引 擎 的 槽 是 稀疏 的 ， 故 还 需 通 过 Recorder Header 的 n_owned 
进行 进一步 的 判断 ， 如 InnoDB 存 储 引 擎 需要 找 主 键 a 为 5 的 记录 ， 通 过 二 
又 查找 Page Directory 的 槽 ， 可 以 定位 记录 的 相对 位 置 在 00 e5 处 ， 找 到 
行 记 录 的 实际 位 置 0xc0e5。 














0000cOeO 04 00 28 00 22 00 00 00 04 OO 00 OO 51 6d ee 80|..(.".......Qm..| 
0000cOfO 00 00 OO 2d O1 10 69 69 69 69 69 69 69 69 69 69|...-..iiiiiiiiii| 
0000c100 Qa 00 00 00 30 00 22 00 00 00 05 00 00 00 51 6d|....0."....... Qm| 
0000c110 ef 80 00 00 00 2d 01 10 6e 6e 6e 6e 6e 6e 6e 6e|.....-..nnnnnnnn| 
0000c120 6e 6e Oa 00 00 00 38 00 22 00 00 00 06 00 OO 00|nn.... Bis x aset ud 


0000c130 51 6d fO 80 00 00 00 2d O1 10 71 71 71 71 71 71|Qm..... -..qqqqqq| 
0000ci40 71 71 71 71 ga 00 00 00 40 00 22 00 00 00 07 OO|qqqq....@."..... 








可 以 看 到 第 一 行 的 记录 是 4， 不 是 我 们 要 找 的 6， 但 是 可 以 发 现 前 面 
的 5 字 节 的 Record Header 为 04 00 28 00 22。 找 到 4 一 8 位 表示 n_owned 值 得 
部 分 ， 该 值 为 4， 表 示 该 记录 有 4 个 记录 ， 因 此 还 需要 进一步 查找 ， 通 过 
recorder header 最 后 两 个 字 节 的 偏 移 量 0x0022 找 到 下 一 条 记录 的 位 置 
0xc107， 这 才 是 最 终 要 找 的 主键 为 5 的 记录 。 


这 节 通 过 一 个 示例 深入 浅 出 地 分 析 了 数据 页 中 各 信息 的 存储 ， 相 信 
这 对 于 用 户 今后 更 好 地 理解 InnoDB 存 储 引 擎 和 优化 数据 库 带 来 益处 。 











4.5 Named File Formats 机 . 制 | 


随 着 InnoDB 存 储 引 苟 的 发 展 ， 新 的 页 数据 结构 有 时 用 来 支持 新 的 
功能 特性 。 比 如 前 面 提 到 的 InnoDB 1.0.x 版 本 提供 了 新 的 页 数据 结构 来 
支持 表 压 缩 功 能 ， 完 全 的 溢出 (Off ”page〉 大 变 长 字符 类 型 字段 的 存 
储 。 这 些 新 的 页 数据 结构 和 之 前 版 本 的 页 并 不 兼容 ， 因 此 从 ImnoDB 
1.0.x 版 本 开始 ，InnoDB 存 储 引 通过 Named File Formats 机 制 来 解决 不 同 
版 本 下 页 结构 兼容 性 的 问题 。 


InnoDB 存 储 引 苟 将 1.0.x 版 本 之 前 的 文件 格式 (fie format) 定义 为 
Antelope， 将 这 个 版 本 文 持 的 文件 格式 定义 为 Barracuda。 新 的 文件 格式 
总 是 包含 于 之 前 的 版 本 的 页 格式 。 风 4-8 显 示 了 Barracuda 文 件 格式 和 
Antelope 文 件 格 式 之 间 的 关系 ，Antelope 文 件 格式 有 Compact 和 Redudant 
的 行 格 式 ，Barracuda 文 件 格 式 既 包括 了 Antelope 所 有 的 文件 格式 ， 另 外 
新 加 入 了 之 前 已 经 提 到 过 的 Compressed 和 Dynamic 行 格式 。 






















Barracuda Flle Format 


Antelope File Format 








图 48 文件 格式 


InnoDB Plugin 的 官方 手册 中 提 到 了 ， 未 来 版 本 的 InnoDB 存 储 引 擎 
还 将 引入 新 的 文件 格式 ， 此 文件 格式 的 名 称 取 自 动物 的 名 字 【〈 这 个 学 
Apple 的 命名 方式 ? ) ， 并 按照 字母 排序 进行 命名 。 我 翻阅 了 源 代码 ， 
发 现 目前 已 经 定义 好 的 文件 格式 有 : 











/**List of animal names representing file format.*/ 
static const char*file format name map[]-t 
"Antelope", 
"Barracuda" 
"Cheetah", 
"Dragon", 

" 


"Fox", 
"Gazelle", 
"Hornet", 
"Impala", 
"Jaguar", 
"Kangaroo", 
"Leopard", 
"Moose", 
"Nautilus", 
"Ocelot", 
"Porpoise", 





参数 innodb_file_ format 用 来 指定 文件 格式 ， 可 以 通过 下 面 的 方式 来 
查看 当前 所 使 用 的 nnoDB 存 储 引擎 的 文件 格式 。 





mysql>SELECT@@version\G; 
C(———————————— K 
@@version:5.1. P 

1 row in set(0.0 ec) 

mysq1- SHOW VARTASLES LIKE'innodb_version'\G; 
JOOOOOOOOOOOROOOOOOOOOOOOOOOR] | pj FICS IIIA III III II Ie 
cas name : innodb | version 

Value:1.0.4 

1 row. in set(0.00 sec) 

mysql1- SHOW VARIABLES LIKE' PURUS file format'*6; 

A r"—— 
Variable name:innodb file Format 

Value: Barracuda 

1 row in set(0.00 sec) 





ZJinnodb file format checkH13 fs M = Ail InnoDB E fig 5| SE EIER 
式 的 支持 上 度 ， 该 值 默 认为 ON， 如 果 出 现 不 支持 的 文件 格式 ， 用 户 可 能 
在 错误 日 志文 件 中 看 到 类 似 如 下 的 错误 : 





InnoDB:Warning:the system tablespace is in a 
file format that this version doesn't support 





46 约束 
4.6.1 数据 完整 性 

关系 型 数据 库 系 统 和 文件 系统 的 一 个 不 同 点 是 ， 关 系数 据 库 本 喘 能 
保证 存储 数据 的 完整 性 ， 不 需要 应 用 程序 的 控制 ， 而 文件 系统 一 般 需 要 
在 程序 端 进行 控制 。 当 前 几乎 所 有 的 关系 型 数据 库 都 提供 了 约束 
(constraint) 机 制 ， 访 机 制 提 供 了 一 条 强大 而 简易 的 途径 来 保证 数据 库 
中 数据 的 完整 性 。 一 般 来 说 ， 数 据 完整 性 有 以 下 三 种 形式 : 

实体 完整 性 保证 表 中 有 一 个 主键 。 在 InnoDB 存 储 引 擎 表 中 ， 用 户 
可 以 通过 定义 Primary Key 或 Unique Key 约 束 来 保证 实体 的 完整 性 。 用 户 
还 可 以 通过 编写 一 个 触发 器 来 保证 数据 完整 性 。 


域 完整 性 保证 数据 每 列 的 值 满足 特定 的 条 件 。 在 InnoDB 存 储 引擎 
表 中 ， 域 完整 性 可 以 通过 以 下 几 种 途径 来 保证 : 


口 选择 合适 的 数据 类 型 确保 一 个 数据 值 满 足 特定 条 件 。 
口外 键 (Foreign Key) 约束 。 
口 编 写 触 发 器 。 

口 还 可 以 考虑 用 DEFAULT 约 束 作为 强制 域 完 整 性 的 一 个 方面 。 
参照 完整 性 保证 两 张 表 之 间 的 关系 。InnoDB 存 储 引 擎 支持 外 键 ， 
因此 人 允许 用 户 定义 外 键 以 强制 参照 完整 性 ， 也 可 以 通过 编写 触发 器 以 强 

制 执行 。 
对 于 InnoDB 存 储 引擎 本 身 而 言 ， 提 供 了 以 下 几 种 约束 : 





Ll Primary Key 
LlUnique Key 


Ll Foreign Key 


ü Default 


DNOT NULL 


4.6.2 ”约束 的 创建 和 查找 

约束 的 创建 可 以 采用 以 下 两 种 方式 : 

口 表 建 立时 就 进行 约束 定义 

口 利 用 ALTER TABLE 命 令 来 进行 创建 约束 

对 Unique Key (E— zx 5|) 的 约束 ， 用 户 还 可 以 通过 命令 CREATE 
UNIQUE INDEX 来 建立 。 对 于 主键 约束 而 言 ， 其 默认 约束 名 为 
PRIMARY。 而 对 于 Unique ”Key 约束 而 言 ， 默 认 约 束 名 和 列 名 一 样 ， 当 
然 也 可 以 人 为 指定 Unique Key RAF. Foreign Key 约 束 似 乎 会 有 一 


个 比较 神秘 的 默认 名 称 。 下 面 是 一 个 简单 的 创建 表 的 语句 ， 表 上 有 一 个 
主键 和 一 个 唯一 键 : 





mysql>CREATE TABLE u( 
id INT 


7 
->name VARCHAR(20), 

-7id card CHAR(18), 

->PRIMARY KEY(id), 

->UNIQUE KEY(name)); 

Query OK,0 rows affected(0.16 sec) 
mysql>SELECT constraint name,constraint type 
>FROM 


->information_schema.TABLE_CONSTRAINTS 
->WHERE table schema-'mytest'AND table_name='u';\G; 


constraint_name: PRIMARY 
constraint_type:PRIMARY KEY 
2. 


constraint_name:name 
constraint type:UNIQUE 
2 rows in set(0.00 sec) 





可 以 看 到 ， 约 束 名 就 如 之 前 所 说 的 ， 主 键 的 约束 名 为 PRIMARY ， 
唯一 索引 的 默认 约束 名 与 列 名 相同 。 当 然 用 户 还 可 以 通过 ALTER 
iil 并 且 可 以 定义 用 户 所 希望 的 约束 名 ， 如 下 面 这 个 
列子 : 





mysql>ALTER TABLE u 
->ADD UNIQUE KEY uk id card(id card); 
Query OK,0 rows affected(0.19 sec) 
Records:0 Duplicates:0 Warnings:O 
mysql>SELECT constraint name,constraint type 
- >FROM 
->information_schema.TABLE_CONSTRAINTS 
->WHERE table schema-'mytest'AND table_name='u';\G; 
JG OK rer er ere rr Teer r ers rs. 
constraint name:PRIMARY 
constraint type:PRIMARY KEY 
2 


constraint name:name 
constraint type:UNIQUE 


constraint name:uk id card 
constraint type:UNIQUE 
3 rows in set(0.00 sec) 





接着 来 看 Foreign Key 的 约束 。 为 了 创建 Foreign Key, HP Zi ll EE 
另 一 张 表 ， 例 如 在 下 面 的 示例 中 创建 表 p。 





mysql>CREATE TABLE p( 

->id INT, 

->u_id INT, 

->PRIMARY KEY(id), 

-— FOREIGN KEY(u id)REFERENCES p(id)); 

Query OK,0 rows affected(0.13 sec) 

mysql>SELECT constraint name,constraint type 

- >FROM 

->information_schema. TABLE_CONSTRAINTS 

->WHERE table schema-'mytest'and table_name='p'\G; 
JOOOOOOOOOOOOODOOOOOOOOOUOR I 6 Q yi EI III ICI IIIA III Ie 
constraint name:PRIMARY 

constraint type:PRIMARY KEY 
JOOOOOOOOOOOROROOOOOOOOOOOER KO p RCOOOOCOOOOOOOOOOIOOOOOROROR 
constraint name:p ibfk 1 

constraint type:FOREIGN KEY 

2 rows in set(0.00 sec) 





在 上 面 的 例子 中 ， 通 过 information_schema 架 构 下 的 表 
TABLE_CONSTRAINTS 来 查看 当前 MySQL 库 下 所 有 的 约束 信息 。 对 于 
Foreign Key 的 约束 的 命名 ， 用 户 还 可 以 通过 查看 表 
REFERENTIAL_CONSTRAINTS， 并 且 可 以 详细 地 了 人 解 外 键 的 属性 ， 

如 : 





mysql>SELECT*FROM 
->information_schema.REFERENTIAL_CONSTRAINTS 
->WHERE constraint_schema='mytest'\G; 
JOOOOOOOOOOOOOOOOOOIOOOOOOR] Tp Qi EITC CIC III III III IE 
CONSTRAINT CATALOG:NULL 

CONSTRAINT SCHEMA:test2 

CONSTRAINT NAME:p ibfk 1 

UNIQUE CONSTRAINT CATALOG:NULL 

UNIQUE CONSTRAINT SCHEMA:test2 

UNIQUE CONSTRAINT NAME:PRIMARY 
MATCH_OPTION: NONE 

UPDATE_RULE: RESTRICT 

DELETE_RULE: RESTRICT 

TABLE NAME:p 

REFERENCED TABLE NAME:p 

1 row in set(0.00 sec) 


二 一 


4.6.3 ”约束 和 索引 的 区 别 


在 前 面 的 小 节 中 已 经 看 到 Primary Key 和 Unique Key 的 约束 ， 有 人 不 
禁 会 问 : XC NL GE S BAS? 那 约 束 和 索引 有 什么 区 别 
呢 ? 


的 确 ， 当 用 户 创 建 了 一 个 唯一 索引 束 创 建 了 一 个 唯一 的 约束 。 但 是 
约束 和 索引 的 概念 还 是 有 所 不 同 的 ， 约 束 更 是 一 个 逻辑 的 概念 ， 用 来 保 
证 数据 的 完整 性 ， 而 索引 是 一 个 数据 结构 ， 既 有 地 辑 上 的 概念 ， 在 数据 
库 中 还 代表 着 物理 存储 的 方式 。 








4.6.4 ”对 错误 数据 的 约束 


在 某 些 默认 设置 下，MySQL 数 据 库 允 许 非 法 的 或 不 正确 的 数据 的 
插入 或 更 新 ， 叉 或 者 可 以 在 数据 库 内 部 将 其 转化 为 一 个 合法 的 值 ， 如 癌 
NOT NULL 的 字段 插入 一 个 NULL 值 ，MySQL 数 据 库 会 将 其 更 改 为 0 再 
进行 插入 ， 因 此 数据 库 本 身 没 有 对 数据 的 正确 性 进行 约束 。 例 如 : 








mysql>CREATE TABLE a( 

->id INT NOT NULL, 

->date DATE NOT NULL); 

Query OK,0 rows affected(0.13 sec) 
mysql>INSERT INTO a 

->SELECT NULL, '2009-02-30'; 

Query OK,1 row affected,2 warnings(0.04 sec) 
Records:1 Duplicates:0 Warnings: 

mysq1- SHOW WARNINGS\G; 


Level:Warning 

Code:1048 

Message:Column'id'cannot be null 

FAI IIIT ITC TIC A pup CR I RR RO IO TOTO IO IOI IO A 
Level:Warning 

Code :1265 

Message:Data truncated for column'date'at row 1 

2 rows in set(@.00 sec) 

mysql>SELECT*FROM a\G; 


id:0 
date:0000-00-00 
1 row in set(0.00 sec) 





在 上 述 例子 中 ， 首 先 向 NOT_ NULL 的 列 插入 了 一 个 NULL 值 ， 同 时 
向 列 date 插 入 了 一 个 非法 日 期 2009-02-30'。 “奇怪 ”的 是 MySQL 数 据 库 并 
没有 报错 ， 而 是 显示 了 警告 (warning) 。 如 果 用 户 想 通过 约束 对 于 数 
据 库 非法 数据 的 插入 或 更 新 ， 即 MySQL 数 据 库 提示 报错 而 不 是 警告 ， 
那么 用 户 必须 设置 参数 sql_mode， 用 来 严格 审核 输入 的 参数 ， 如 : 








mysql>SET sql mode-'STRICT TRANS TABLES'; 

Query OK,0 rows affected(0.00 sec) 

mysql>INSERT INTO a 

- >SELECT NULL, '2009-02-30'; 

ERROR 1048(23000):Column'id'cannot be null 

mysql>INSERT INTO a 

->SELECT 1, '2009-02-30'; 

ERROR 1292(22007):Incorrect date value: '2009-02-30'for column'date'at row 1 





通过 设置 参数 sql_mode 的 值 为 STRICT_TRANS_TABLES， 这 次 
MySQL 数 据 库 对 于 输入 值 的 合法 性 进行 了 约束 ， 而 且 针 对 不 同 的 错 
误 ， 提 示 的 错误 内 容 也 都 不 同 。 参 数 sql_mode 可 设 的 值 有 很 多 ， 有 具体 可 
参考 MySQL 官 方 手册 。 


4.6.5 ENUM 和 SET 约束 


MySQL 数 据 库 不 支持 传统 的 CHECK 约 束 ， 但 是 通过 ENUM 和 SET 
类 型 可 以 解决 部 分 这 样 的 约束 需求 。 例 如 表 上 有 一 个 性 别 类 型 ， 规 定 域 
one 能 是 male 或 female， 在 这 种 情况 下 用 户 可 以 通过 ENUM 类 型 来 
进行 约束 。 





mysql>CREATE TABLE a( 
>id INT, 


->sex ENUM('male', 'female')); 
Query OK,0 rows affected(0.12 sec) 
mysql>INSERT INTO a 
->SELECT 1,'female'; 
Query OK,1 row affected(0.03 sec) 
Records:1 Duplicates:0 Warnings:0 
mysql> INSERT INTO a 
->SELECT 2,'bi' 
Query OK,1 row affected, 1 warning(0.03 sec) 
Records: 1 Duplicates:0 Warnings:1 





可 以 看 到 ， 在 上 述 例子 中 对 第 二 条 记录 的 插入 依然 是 报 了 警告 。 
此 如 果 想 实现 CHECK 约 束 ， 还 需要 配合 设置 参数 sql mode. 





mysql>SET sql mode-'STRICT TRANS TABLES'; 
Query OK,0 rows affected(0.00 sec) 
mysq1> INSERT INTO a 
= 一 SELECT 2,'bi 
ERROR 1265(01090): Data truncated for column'sex'at row 1 








这 次 对 非法 的 输入 值 进 行 了 约束 ， 但 是 只 限于 对 离散 数值 的 约束 ， 
对 于 传统 CHECK 约 束 文 持 的 连续 值 的 范围 约束 或 更 复杂 的 约束 ， 
D. ee KBE JGBE 73 7J. ix FH" s ERE I PU si RSE LT T 
域 的 约束 。 


4.6.6 fit as Zu 


通过 前 面 小 节 的 介绍 ， 用 户 已 经 知道 完整 性 约束 通常 也 可 以 使 用 触 
发 右 来 实现 ， 因 此 在 T ROCECERE E OMAR BOE TET 


触发 器 的 作用 是 在 执行 INSERT、DELETE 和 UPDATE 命 令 之 前 或 
之 后 自动 调用 SQL 命令 或 存储 过 程 。MySQL 5.0 对 触发 器 的 实现 还 不 是 
非常 完善 ， 限 制 比较 多 ， 而 从 MySQL 5.1 开 始 触发 器 已 经 相对 稳定 ， 功 
能 也 较 之 前 有 了 大 幅 的 提高 。 


创建 触发 器 的 命令 是 CREATE TRIGGER, 只 有 有 具备 Super 权 限 的 
MySQL 数 据 库 用 户 才 可 以 执行 这 条 命令 : 











DEATRER= {user | CURRENT_USER}] 
TRIGGER trigger name BEFORE|AFTER INSERT |UPDATE | DELETE 
ON tbl_name FOR EACH ROW trigger_stmt 





最 多 可 以 为 一 个 表 建 立 6 个 触发 器 ， 即 分 别 为 INSERT、UPDATE、 
mu ee T BEFORE 和 AFTER 代表 触发 
器 发 生 的 时 间 ， 表 示 是 在 每 行 操作 的 之 前 发 生还 是 之 后 发 生 。 当 前 
MySQL 数 据 库 只 支持 FOR EACH ROW 的 触发 方式 ， 即 按 每 行 记 录 进 行 
触发 ， 不 支持 像 DB2 的 FOR EACH STATEMENT 的 触发 方式 。 


通过 触发 器 ， 用 户 可 以 实现 MySQL 数 据 库 本 身 并 不 支持 的 一 些 特 
性 ， 如 对 于 传统 CHECK 约 束 的 文 持 ， 物 化 视图 、 高 级 复制 、 审 计 等 特 
性 。 这 里 先 关 注 触 发 器 对 于 约束 的 支持 。 


假设 有 张 用 户 消费 表 ， 每 次 用 户 购买 一 样 物 品 后 其 金额 都 是 减 的 ， 
车 这 时 有 “不 怀 好 意 ” 的 用 户 做 了 类 似 减 去 一 个 负 值 的 操作 ， 这 样 用 户 的 
钱 没 减少 反而 会 不 断 增 加 ， 如 : 














"ys E TABLE userc ash( 
rid INT NOT NULL 

rT h INT UNSIGNED NOT NULL); 
Query OK,0 rows affected(0.11 sec) 
mys ql INSERT INTO usercash 
QUESO, 1,1000; 
Quer s row affecte pum s sec) 
Reco a Duplicates:0 Warnings:0 
mys PI UPDATE usercash 

->SET cash=cash-(-2 riesce Pap pee id-1; 
Query OK,1 row affecte nie ec) 
Rows matched:1 Changed:1 


he | 


上 述 运行 的 SQL 语句 对 数据 库 来 说 没有 任何 问题 ， 都 可 以 正 篆 的 运 
行 ， 不 会 报错 。 但 是 从 业务 的 过 和 辑 上 来 说 ， 这 是 绝对 错 昔 误 的 。 因 为 消费 
总 是 意味 着 减 去 一 个 正 值 ， 而 不 是 负 值 ， 所 以 这 时 要 通过 触发 器 来 约束 
这 个 逻辑 行为 ， 可 以 进行 如 下 设置 : 











mysql>CREATE TABLE usercash err log( 
->userid INT NOT NULL, 

-201ld cash INT UNSIGNED NOT NULL, 
-2new cash INT UNSIGNED NOT NULL, 
->user VARCHAR(30), 

->time DATETIME); 

Query OK,0 rows affected(0.13 sec) 
mysql>DELIMITER$$ 

Query OK,0 rows affected(0.00 sec) 
mysql>CREATE TRIGGER tgr usercash update BEFORE UPDATE ON usercash 
->FOR EACH ROW 

- BEGIN 

->IF new.cash-old.cash>0 THEN 

-> INSERT INTO usercash err log 
->SELECT old.userid,old.cash,new.cash,USER(), NOW() ; 
->SET new.cash=old.cash; 

->END IF; 

->END; 

->$$ 

Query OK,0 rows affected(0.00 sec) 
mysql>DELIMITER $$ 

Query OK,0 rows affected(0.00 sec) 





上 述 例子 首先 创建 了 一 张 表 usercash_err_log 来 记录 错误 数值 更 新 的 
日 志 ， 然 后 创建 了 进行 约束 操作 的 触发 器 tgr_usercash_update， 其 类 型 
为 BEFORE。 触 发 器 首先 判断 新 、 旧 值 之 间 的 差 值 ， 在 正常 情况 下 消费 
总 是 减 的 ， 新 值 应 该 总 是 小 于 原来 的 值 ， 因 此 大 于 原 值 的 数据 被 判断 为 
非法 的 输入 ， 将 cash 值 设 定 为 原来 的 值 ， 并 将 非法 的 数据 更 新 插入 表 

usercash em ljog。 再 次 运行 上 述 的 SQL 语句 : 





mysql>DELETE FROM usercash; 

Query OK,1 row affected(0.02 sec) 
mysql>INSERT INTO usercash 
->SELECT 1,1000; 

Query OK,1 row affected(0.03 sec) 
Records:1 Duplicates:0 Warnings:O 
mysql>UPDATE usercash 

->SET cash=cash-(-20) 

-二 WHERE userid=1; 

Query OK,0 rows affected(0.02 sec) 
Rows matched:1 Changed:0 Warnings:0 
mysql>SELECT*FROM usercash\G; 


userid:1 

cash:100 

1 row in set(0.00 sec) 
mysql>SELECT*FROM usercash B ev 
FOI E Je E E Fe Je E E He HEE "'"——-——————— A 
userid:1 

old_cash:1000 

new_cash:1020 

user :root@localhost 

time:2009-11-06 11:49:49 
Message:Column'id'cannot be null 

1 row in set(0.00 sec) 








可 以 看 到 这 次 对 于 异常 的 数据 更 新 通过 触发 器 将 其 保存 到 了 
cnm em log。 此 外 该 触 发 器 还 记录 了 操作 该 SQL 语句 的 用 户 及 时 
间 。 通 过 上 述 的 例子 可 以 发 现 ， 创 建 触 发 器 也 是 实现 约束 的 一 种 手段 和 


方法 。 


4.6.7 ”外 键 约束 


外 键 用 来 保证 参照 完整 性 ，MySQL 数 据 库 的 MyISAM 存 储 引擎 本 身 
并 不 支持 外 键 ， 对 于 外 键 的 定义 只 是 起 到 一 个 注释 的 作用 。 而 InnoDB 
存储 引擎 则 完整 支持 外 键 约束 。 外 键 的 定义 如 下 : 





prai 


[ON DELETE reference_option] 
[ON UPDATE reference_option] 
renc i 





用 户 可 以 在 执行 CREATE TABLE 时 就 添加 外 键 ， 也 可 以 在 表 创 建 
后 通过 ALTER TABLE 命 令 来 添加 。 一 个 简单 的 外 键 的 创建 示例 如 下 : 





mysql>CREATE TABLE parent( 
->id INT NOT NULL, 

->PRIMARY KEY(id) 

- >) ENGINE=INNODB; 

uery OK,0 rows affected(0.13 sec) 
mysql>CREATE TABLE child( 

->id INT,parent id INT, 

-2 FOREIGN KEY(parent id)REFERENCES parent(id) 
- > )JENGINE-INNODB; 

K,O rows affected(0.16 sec) 





一 般 来 说 ， 称 被 引用 的 表 为 父 表 ， 引 用 的 表 称 为 子 表 。 外 键 定 义 时 
的 ON DELETE 和 ON UPDATE 表 示 在 对 父 表 进行 DELETE 和 UPDATE 操 
作 时 ， 对 子 表 所 做 的 操作 ， 可 定义 的 子 表 操作 有 : 


LICASCADE 





USET NULL 
LINO ACTION 


LIRESTRICT 





CASCADE 表 示 当 父 表 发 生 DELETE 或 UPDATE 操 作 时 ， 对 相应 的 
子 表 中 的 数据 也 进行 DELETE 或 UPDATE 操 作 。SET NULL 表 示 当 父 表 
发 生 DELETE 或 UPDATE 操 作 时 ， 相 应 的 子 表 中 的 数据 被 更 新 为 NULL 
值 ， 但 是 子 表 中 相对 应 的 列 必 须 允 许 为 NULL 值 。NO ACTION 表 示 当 父 
表 发 生 DELETE 或 UPDATE 操 作 时 ， 抛 出 错误 ， 不 允许 这 类 操作 发 生 。 





RESTRICT 表 示 当 父 表 发 后 DELETE 或 UPDATE 操 作 时 ， 抛 出 错误 ， 不 
允许 这 类 操作 发 和 后。 如 果 定 义 外 键 时 没有 指定 ON DELETE 或 ON 
UPDATE，RESTRICT 就 是 默认 的 外 键 设 置 。 


在 其 他 数据 库 中 ， 如 Oracle 数 据 库 ， 有 一 种 称 为 延 时 检查 (deferred 
check) 的 外 键 约束 ， 即 检查 在 SQL 语句 运行 完成 后 再 进行 。 而 目前 
MySQL 数 据 库 的 外 键 约束 都 是 即时 检查 (immediate check) ， 因 此 从 上 
面 的 定义 可 以 看 出 ， 在 MySQL 数 据 库 中 NO ACTION 和 RESTRICT 的 功 
能 是 相同 的 。 


在 Oracle 数 据 库 中 ， 对 于 建立 外 键 的 列 ， 一 定 不 要 坊 记 给 这 个 列 加 
上 一 个 索引 。 而 InnoDB 存 储 引擎 在 外 键 建立 时 会 自动 地 对 该 列 加 一 个 
索引 ， 这 和 Microsoft SQL Server 数 据 库 的 做 法 一 样 。 因 此 可 以 很 好 地 避 
免 外 键 列 上 无 索引 而 导致 的 死 锁 问 题 的 产生 。 例 如 在 上 述 的 例子 中 ， 表 
child 创 建 时 只 定义 了 外 键 ， 并 没有 手动 指定 parent_id 列 为 索引 ， 但 是 通 
过 命令 SHOW CREATE TABLE 可 以 发 现 ImnnoDB 存 储 引 擎 自动 为 外 键 约 
束 的 列 parent_id 添 加 了 索引 : 














mysql>SHOW CREATE TABLE chi. nae 


FOI IOI IO IOI ROGER]. pO IO IOI ICR IOI IO IOI RIOR I ae 


ee 
ere te Table:CREATE TABLE'child'( 
idu Er rsen NULL 
USE dA NULL, 


KEY" pa en id' ('pa id'), 
CONSTRAINT" child. Hir 1'FOREIGN KEY('parent  id')REFERENCES'parent' ('id') 
JENGINE= InnoDB DEFAULT CHARSET=utf8 





对 于 参照 完整 性 约束 ， 外 键 能 起 到 一 个 非常 好 的 作用 。 但 是 对 于 数 
据 的 导入 操作 时 ， 外 键 往往 导致 在 外 键 约束 的 检查 上 人 花费 大 量 时 间 。 
为 MySQL 数据 库 的 外 键 是 即时 检查 的 ， 所 以 对 导入 的 每 一 行 都 会 进行 
外 键 检查 。 但 是 用 户 可 以 在 导入 过 程 中 忽视 外 键 的 检查 ， 如 : 














47 视图 


在 MySQL 数 据 库 中 ， 视 图 View) 是 一 个 命名 的 虚 表 ， 它 由 一 个 
SQL 查询 来 定义 ， 可 以 当做 表 使 用 。 与 持久 表 (permanent table) 不 同 
的 是 ， 视 图 中 的 数据 没有 实际 的 物理 存储 。 


4.7.1 视图 的 作用 

视图 在 数据 库 中 发 挥 着 重要 的 作用 。 视 图 的 主要 用 途 之 一 是 被 用 做 
一 个 抽象 装置 ， 特 别 是 对 于 一 些 应 用 程序 ， 程 序 本 身 不 需要 关心 基 表 
(base table) 的 结构 ， 只 需要 按照 视图 定义 来 取 数 据 或 更 新 数据 ， 因 
此 ， 视 图 同时 在 一 定 程度 上 起 到 一 个 安全 层 的 作用 。 


MySQL 数 据 库 从 5.0 版 本 开始 支持 视图 ， 创 建 视图 的 语法 如 下 : 











[OR REPLACE] 
EER {UNDEF INED] MERGE | TEMPTABLEJ] 
EFINER={user | CURI 
E SECURITY (DEFINER|ZNVOKERD} 
e[(co 


Hs phe sae 
[WITH[CASCADED|LOCAL]CHECK OPTION] 














虽然 视图 是 基于 基 表 的 一 个 虚拟 表 ， 但 是 用 户 可 以 对 某 些 视图 进行 
更 新 操作 ， 其 本 质 就 是 通过 视图 的 定义 来 更 新 基本 表 。 一 般 称 可 以 进行 
更 新 操作 的 视图 为 可 更 新 视图 (updatable view) 。 视 图 定义 中 的 WITH 
CHECK OPTION 就 是 针对 于 可 更 新 的 视图 的 ， 即 更 新 的 值 是 否 需 要 检 
查 。 先 看 下 面 的 一 个 例子 : 











mys te eee gers Hi id INT); 
Qu affected(0.13 sec) 
"ys disce PATE. VIEW v ot 


eee FROM t od id<10; 
Query OK,0 rows affected(0.00 sec) 
mys ql> INSERT qud |. t SELECT 20; 
Que OK,1 row es us ur sec) 
rds :1 D uplic ates:0 Warnings:0 
mys qi- SELECT FROM vt 
Empty set(0.00 sec) 





在 上 面 的 例子 中 ， 创 建 了 一 个 id<10 的 视图 v_ t。 但 之 后 向 视图 里 插 
入 了 id 为 20 的 值 ， 插 入 操作 并 没有 报错 。 但 是 用 户 查 询 视 图 还 是 没 能 查 
到 数据 。 接 着 更 改 视 图 的 定义 ， 加 上 WITH CHECK OPTION 选 项 : 











mysql>ALTER VIEW v t 
->AS 


->SELECT*FROM t WHERE id<10 
->WITH CHECK OPTION; 
Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO v_t SELECT 20; 
ERROR 1369(HY000):CHECK OPTION failed'mytest.v_t' 








XXIX MySQL ZU FE OST SECHS HUN se T Tr. MD IP 
CALA E MATE, TAE 7 S. AICP ALA a EUST o 


MySQL 2x48 FEDBAR]— AHMA 2ESHOW TABLES, ar 
2 c ee 下 所 有 的 表 。 但 因为 视图 是 虚 表 ， 同 样 被 作为 表 显 
不 > , 9l H: 











mysql>SHOW TABLES\G; 


Tables_in_mytest: v_t 
2 rows in set(0.00 sec) 








可 见 SHOW TABLES 命 令 把 表 t 和 视图 v_t 都 显示 出 来 了 。 若 用 户 只 
想 查 看 当前 架构 下 的 其 表 ， 可 以 通过 information_schema 架 构 下 的 
TABLE 表 来 查询 ， 并 搜索 表 类 型 为 BASE TABLE 的 表 ，SQL 语 句 如 下 : 








mysql>SELECT*FROM information schema.TABLES 
->WHERE table type-'BASE TABLE' 
->AND table schema- patra geet 
FOI III III III III] pO EORR ROIG GR ROROROGO RO III OK 

TABLE CATALOG: NULL 

TABLE SCHEMA:mytest 

TABLE NAME:t 

TABLE TYPE:BASE TABLE 

ENGINE:InnoDB 

VERSION: 10 

ROW FORMAT:Compact 

TABLE ROWS:1 

AVG ROW LENGTH:16384 

DATA LENGTH:16384 

MAX DATA LENGTH:O 

INDEX LENGTH:O 

DATA FREE:0O 

AUTO. INCREMENT : NULL 

CREATE TIME:2009-11-09 16:27:52 

UPDATE TIME:NULL 

CHECK TIME:NULL 

TABLE COLLATION:utf8 general ci 

CHECKSUM: NULL 

CREATE OPTIONS: 

TABLE COMMENT: 

1 row in set(0.00 sec) 





要 想 查 看 视图 的 一 些 元 数据 (meta data) ， 可 以 访问 
information schema 架 构 下 的 VIEWS 表 ， 该 表 给 出 了 视图 的 详细 信息 ， 
包括 视图 定义 者 (definer) 、 定 义 内 容 、 是 否 是 可 更 新 视图 、 字 符 集 
等 。 如 查询 VIEWS 表 可 得 : 














mysq1>SELECT*FROM 


->information_schema. VIEWS 
->WHERE table_schema=database()\G; 
JOOOOOOOOOOOOOODOOOOOOOOOUOR] | p FU ICICI GI ICICI III III III Ie 
TABLE_CATALOG: NULL 

TABLE SCHEMA:mytest 

TABLE NAME:v t 

VIEW DEFINITION:select'mytest'.'t'.'id'AS'id'from'mytest'.'t'where('mytest'.'t'.'id'-—10) 
CHECK OPTION:CASCADED 

IS UPDATABLE: YES 

DEFINER:rootQlocalhost 

SECURITY TYPE:DEFINER 

CHARACTER SET CLIENT:latini 

COLLATION CONNECTION:latini swedish ci 

1 row in set(0.00 sec) 


A 


4.7.2. 物化 视图 


Oracle 数 据 库 支持 物化 视图 一 一 该 视图 不 是 基于 基 表 的 虚 表 ， 而 是 
根据 基 表 实际 存在 的 实 表 ， 即 物化 视图 的 数据 存储 在 非 易 失 的 存储 设备 
上 。 物 化 视图 可 以 用 于 预先 计算 并 保存 多 表 的 链接 (JOIN) 或 聚集 
(GROUP BY) 等 耗 时 较 多 的 SQL 操作 结果 。 这 样 ， 在 执行 复杂 查询 
时 ， 束 可 以 避免 进行 这 些 耗 时 的 操作 ， 从 而 快速 得 到 结果 。 物 化 视图 的 
好 处 是 对 于 一 些 复杂 的 统计 类 查询 能 直接 查 出 结果 。 在 Microsoft SQL 
Server 数 据 库 中 ， 称 这 种 视图 为 索引 视图 。 


在 Oracle 数 据 库 中 ， 物 化 视图 的 创建 方式 包括 以 下 两 种 : 


DBUILD IMMEDIATE 




















DBUILD DEFERRED 


BUILD IMMEDIATE 是 默认 的 创建 方式 ， 在 创建 物化 视图 的 时 候 就 
生成 数据 ， 而 BUILD DEFERRED 则 在 创建 物化 视图 时 不 生成 数据 ， 以 
后 根据 需要 再 生成 数据 。 


查询 重 写 是 指 当 对 物化 视图 的 基 表 进行 得 询 时 ， 数 据 库 会 目 动 判断 
能 否 通 过 查询 物化 视图 来 下 接 得 到 最 终 的 结果 ， 如 末 可 以 ， 则 避免 了 聚 
集 或 连接 等 这 类 较为 复杂 的 SQL 操 作 ， 直 接 从 已 经 计算 好 的 物化 视图 中 
得 到 所 需 的 数据 。 


物化 视图 的 刷新 是 指 当 基 表 及 生 了 了 DML 操作 后 ， 物 化 视图 何 时 采 
用 哪 种 方式 和 基 表 进行 同步 。 刷 新 的 模式 有 两 种 : 


QON DEMAND 


























UON COMMIT 


ON “DEMAND 意味 着 物化 视图 在 用 户 需 要 的 时 候 进 行 刷 新 ，ON 
COMMIT 意 味 着 物化 视图 在 对 基 表 的 DML 操 作 提 交 的 同时 进行 刷新 。 


而 刷新 的 方法 有 四 种 : 


LIFAST 
LICOMPLETE 
L]IFORCE 
LINEVER 


FAST 刷 新 采用 增 量 刷新 ， 只 刷新 自 上 次 刷新 以 后 进行 的 修改 。 
COMPLETE 刷 新 是 对 整个 物化 视图 进行 完全 的 刷新 。 如 果 选 择 FORCE 
方式 ， 则 数据 库 在 刷新 时 会 去 判断 是 否 可 以 进行 快速 刷新 ， 如 果 可 以 ， 
则 采用 FAST 方 式 ， 和 否则 采用 COMPLETE 的 方式 。NEVER 是 指 物化 视图 
不 进行 任何 刷新 。 


MySQL 数 据 库 本 身 并 不 文 持 物化 视图 ， 换 名 话说 ，MySQL 数 据 库 
中 的 视图 总 是 虚拟 的 。 但 是 用 户 可 以 通过 一 些 机 制 来 实现 物化 视图 的 功 
能 。 例 如 要 创建 一 个 ON DEMAND 的 物化 视图 还 是 比较 简单 的 ， 用 户 只 
再 定时 把 数据 导入 到 另 一 张 表 。 例 如 有 如 下 的 订单 表 ， 记 录 了 用 户 采 购 
电脑 设备 的 信息 : 











mysql>CREATE TABLE Orders 
ie 


->order_id INT UNSIGNED NOT NULL AUTO_INCREMENT, 
->product_name VARCHAR(30)NOT NULL, 
->price DECIMAL(8,2)NOT NULL, 
->amount SMALLINT NOT NULL, 
->PRIMARY KEY(order id) 
-2)JENGINE-InnoDB; 

Query OK,0 rows affected(0.13 sec) 
mysql>INSERT INTO Orders VALUES 

-7 (NULL, 'CPU',135.5,1), 

-2 (NULL, 'Memory',48.2,3), 

-7 (NULL, 'CPU',125.6,3), 

-7 (NULL, 'CPU',105.3,4) 

EE 


i 
Query OK,4 rows affected(0.03 sec) 
Records:4 Duplicates:0 Warnings:O 
mysql>SELECT*FROM Orders\G; 


order_id:1 
product_name:CPU 
price:135.50 
amount :1 


order_id:2 
product_name:Memory 
price:48.20 
amount :3 


order_id:3 
product_name:CPU 
price:125.60 
amount :3 


order_id:4 
product_name:CPU 
price:105.30 

amount :4 

4 rows in set(0.00 sec) 





接着 建立 一 张 物 化 视图 的 基 表 ， 用 来 统计 每 件 物品 的 信息 ， 如 : 


i 


mysql>CREATE TABLE Orders MV( 

-—product name VARCHAR(30)NOT NULL 

-—,price sum DECIMAL(8,2)NOT NULL 

-,amount sum INT NOT NULL 

-—,price avg FLOAT NOT NULL 

->,orders_cnt INT NOT NULL 

->,UNIQUE INDEX(product name) 

->)i 

Query OK,0 rows affected(0.13 sec) 

mysql>INSERT INTO Orders MV 

->SELECT product name 

->,SUM(price),SUM(amount ), AVG( price) 

->,COUNT(*) 

->FROM Orders 

->GROUP BY product_name; 

Query OK,2 rows affected(0.02 sec) 

Records:2 Duplicates:0 Warnings:0 

mysql> 

mysql> 

mysql >SELECT" FROM Orders _MV\G; 
FOCI TOTO TOTO IOI TO TO IOI 1. T Ow ISIS IIIS III I III IO I I 

product_name:CPU 

price: 366.40 

amount_sum:8 

price_avg:122.133 

orders. | cnt:3 


product name:Memory 
price:48.20 

amount sum:3 

price avg:48.2 

orders cnt:1 

2 rows in set(0.00 sec) 





在 上 面 的 例子 中 ， 把 物化 视图 定义 为 一 张 表 Orders MV. KAVA 
_MV 结 尾 ， 以 便 能 让 DBA 很 好 地 理解 这 张 表 的 作用 。 通 过 上 面 的 方 
式 ， 用 户 就 拥有 了 一 个 统计 信息 的 物化 视图 。 如 果 是 要 实现 ON 
DEMAND 的 物化 视图 ， 只 需 把 表 清 空 ， 重 新 导入 数据 即 可 。 当 然 ， 这 
是 COMPLETE 的 刷新 方式 ， 要 实现 FAST 的 方式 ， 也 是 可 以 的 ， 只 不 过 
稍微 复杂 点 ， 需 要 记录 上 次 统计 时 order_id 的 位 置 。 


但 是 ， 如 果 要 实现 ON COMMIT 的 物化 视图 ， 就 不 像 上 面 这 么 简单 
了 。 在 Oracle 数 据 库 中 是 通过 物化 视图 日 志 来 实现 的 ， 很 显然 MySQL 数 
据 库 没有 这 个 日 志 ， 不 过 通过 触发 器 同样 可 以 达到 这 个 目的 ， 首 先 需 要 
Xf K Orders££ — fih as, INIT: 

















DELIMITER$$ 

CREATE TRIGGER tgr_Orders_insert 

AFTER INSERT ON Orders 

FOR EACH ROW 

BEGIN 

SET@old_price_sum=0; 

SETQold amount sum-0; 

SETQold price avg-90; 

SETQold orders cnt-0; 

SELECT IFNULL(price sum,0),IFNULL(amount sum,0),IFNULL(price avg,0),IFNULL(orders cnt,0) 
FROM Orders MV 

WHERE product name-NEW.product name 

INTOQold price sum,Qold amount sum,Qold price avg,Qold orders cnt; 

SETQnew price sum- Qold | price. sum+NEW. price; 

SET@new_amount_sum=@old_amount_sum+NEW. amount; 

SET@new_orders_cnt=@old_orders_cnt+1; 

SET@new_price_avg=@new_price_sum/@new_orders_cnt; 

REPLACE INTO Orders_MV 

VALUES(NEW.product name,Qnew price sum,Qnew amount sum,Qnew price avg,Qnew orders cnt); 
END; 


$$ 
DELIMITER; 
二 一 


上 述 代 码 创 建 了 一 个 INSERT 的 触发 器 ， 每 次 INSERT 操 作 都 会 重新 
统计 表 Orders_MV 中 的 数据 。 接 着 运行 以 下 插入 操作 ， 并 观察 之 后 物化 
视图 表 Orders MV 中 的 记录 。 








mysql>INSERT INTO Orders VALUES(NULL, 'SSD', 299,3); 
Query OK,1 row affected,1 warning(0.03 sec) 
mysql>INSERT INTO Orders VALUES(NULL, 'Memory',47.9,5) 
Query OK,1 row affected(0.03 sec) 

mysql>SELECT*FROM Orders MV*G; 


amount sum:8 
price avg:122.133 
orders cnt:3 


FOI TOTO TOTO IOI TO TO IO I 2. TOW RII OCI III I II IER 
product_name:Memory 

price:96.1! 

amount sum:8 

price avg:48.05 

orders cnt:2 

FOI TO TOTO IO IOI TO TO IOI STOW III ICI III I II Ok 


product_name:SSD 
price:299.00 
amount_sum:3 
price_avg:299 
orders_cnt:1 

3 rows in set(0.00 sec) 





可 以 发 现在 插入 两 条 新 的 记录 后 ， 直 接 查 询 Orders_MV 表 就 能 得 到 
统计 信息 。 而 不 像 之 前 需要 重新 进行 SQL 语句 的 统计 ， 这 就 实现 了 
ON_COMMIT 的 物化 视图 功能 。 需 要 注意 的 是 ，Orders 表 可 能 还 会 有 
UPDATE 和 DELETE 的 操作 ， 所 以 应 该 还 需要 实现 DELETE 和 UPDATE 
的 触发 器 ， 这 就 留 给 读者 自己 去 实现 了 。 


通过 触发 器 ， 在 MySQL 数 据 库 中 实现 了 类 似 物 化 视图 的 功能 。 但 
是 MySQL 数 据 库 本 喘 并 不 文 持 物化 视图 ， 因 此 对 于 物化 视图 文 持 的 碍 
Rewrite) 功能 就 显得 无 能 为 力 ， 用 户 只 能 在 应 用 程序 端 

一 些 控制 。 














分 区 功能 并 不 是 在 存储 引擎 层 完成 的 ， 因 此 不 是 只 有 InnoDB 存 储 
引擎 支持 分 区 ， 常 见 的 存储 引擎 MyISAM、NDB 等 都 支持 。 但 也 并 不 是 
所 有 的 存储 引擎 都 支持 ， 如 CSV、FEDORATED、MERGE 等 就 不 支 
C a E ae 
E. 


MySQL 数 据 库 在 5.1 版 本 时 添加 了 对 分 区 的 支持 。 分 区 的 过 程 是 将 
一 个 表 或 索引 分 解 为 多 个 更 小 、 更 可 管理 的 部 分 。 束 访问 数据 库 的 应 用 
而 言 ， 从 怕 辑 上 讲 ， 只 有 一 个 表 或 一 个 索引 ， 但 是 在 物理 上 这 个 表 或 索 
引 可 能 由 数 十 个 物理 分 区 组 成 。 每 个 分 区 都 是 独立 的 对 象 ， 可 以 独自 处 
理 ， 也 可 以 作为 一 个 更 大 对 象 的 一 部 分 进行 处 理 。 


MySQL 数 据 库 文 持 的 分 区 类 型 为 水 平分 区 a， 并 不 文 持 垂 直 分 区 
2。 此 外 ，MySQL 数 据 库 的 分 区 是 局 部 分 区 索引 ， 一 个 分 区 中 既 存 放 了 
数据 又 存放 了 索引 。 而 全 局 分 区 是 指 ， 数 据 存 放 在 各 个 分 区 中 ， 但 是 所 
有 数据 的 索引 放 在 一 个 对 象 中 。 目 前 ，MySQL 数 据 库 还 不 文 持 全 局 分 


区 。 




















可 以 通过 以 下 命令 来 查看 当前 数据 库 是 否 启 用 了 分 区 功能 : 





mysql>SHOW VARIABLES LIKE'%partition%'\G; 
EEEE OUOU OOOO OOO OEE] p OOO OEEO OEE 





也 可 以 通过 命令 SHOW PLUGINS 来 查看 : 





mysql>SHOW PLUGINS\G; 
Name:partition 

Status :ACTIVE 

Type: STORAGE ENGINE 
Library:NULL 

License: GPL 


9 rows in set(0.01 sec) 





大 多 数 DBA 会 有 这 样 一 个 误区 ， 只 要 启用 了 分 区 ， 数 据 库 就 会 运行 
得 更 快 。 这 个 结论 是 存在 很 多 问题 的 。 就 我 的 经 验 看 来 ， 分 区 可 能 会 给 
某 些 SQL 语句 性 能 带 来 提高 ， 但 是 分 区 主要 用 于 数据 库 高 可 用 性 的 管 
理 。 在 OLTP 应 用 中 ， 对 于 分 区 的 使 用 应 该 非常 小 心 。 总 之 ， 如 果 只 是 
一 味 地 使 用 分 区 ， 而 不 理解 分 区 是 如 何 工作 的 ， 也 不 清楚 你 的 应 用 如 何 
使 用 分 区 ， 那 么 分 区 极 有 可 能 会 对 性 能 产生 负面 的 影响 。 


当前 MYSQL 数据 库 文 持 以 下 几 种 类 型 的 分 区 。 


DRANGE 分 区 : 行 数据 基于 属于 一 个 给 定 连 续 区 间 的 列 值 被 放 入 
分 区 。MySQL 5.5 开 始 支 持 RANGE COLUMNS 的 分 区 。 














DLIST 分 区 : 和 RANGE 分 区 类 型 ， 只 是 LIST 分 区 面向 的 是 离散 的 
值 。MySQL 5.5 开 始 支 持 LISTCOLUMNS 的 分 区 。 


DHASH 分 区 : 根据 用 户 自 定义 的 表达 式 的 返回 值 来 进行 分 区 ， 返 
回 值 不 能 为 负数 。 


DKEY 分 区 : 根据 MySQL 数 据 库 提供 的 哈 希 函数 来 进行 分 区 。 
不 论 创 建 何 种 类 型 的 分 区 ， 如 果 表 中 存在 主键 或 唯一 索引 时 ， 分 区 


列 必须 是 唯一 索引 的 一 个 组 成 部 分 ， 因 此 下 面 创建 分 区 的 SQL 语 句 会 产 
生 错 误 。 





mysql>CREATE TABLE t1( 
-—coli INT NOT NULL, 
->col2 DATE NOT NULL, 
->col3 INT NOT NULL, 
->col4 INT NOT NULL, 
->UNIQUE KEY(col1,col2) 
> 


->PARTITION BY HASH(co13) 


->PARTITIONS 4; 
ERROR 1503(HY000):A PRIMARY KEY must include all columns in the table's partitioning function 








唯一 索引 可 以 是 允许 NULL 值 的 ， 并 且 分 区 列 只 要 是 唯一 索引 的 一 
个 组 成 部 分 ， 不 再 要 整个 唯一 索引 列 都 是 分 区 列 ， 如 : 





mysql>CREATE TABLE t1( 

->col1 INT NULL, 

->col2 DATE NULL, 

->col3 INT NULL, 

->col4 INT NULL, 

->UNIQUE KEY(col1,col2,co13,col14) 
> 


->PARTITION BY HASH(col3) 
->PARTITIONS 4; 
Query OK,0 rows affected(0.53 sec) 





如 果 建 表 时 没有 指定 主键 ， 唯 一 索引 ， 可 以 指定 任何 一 个 列 为 分 区 
列 ， 因 此 下 面 两 名 创建 分 区 的 SQL 语句 都 是 可 以 正确 运行 的 。 








CREATE TABLE t1( 
coli INT NULL, 
col2 DATE NULL, 
COl3 INT NUL 
col4 INT NUL 


arr 


e nodb 
PARTITION BY HASH(co13) 
PARTITIONS 4; 

CREATE TABLE t1( 

coli INT NUL 
col2 DATE NULL, 
col3 INT NUL 
col4 INT NUL 
key(col4) 
engine=in 





Q. Freer 
oft ~ 


ne=1 
PARTITION BY HASH(co13) 
PARTITIONS 4; 


[LI 水 平分 区 ， 指 将 同一 表 中 不 同行 的 记录 分 配 到 不 同 的 物理 文件 中 。 
已] 垂直 分 区 ， 指 将 同一 表 中 不 同 列 的 记录 分 配 到 不 同 的 物理 文件 中 。 














48.2. 4j[X2878 
1.RANGE | [X 


我 们 介绍 的 第 一 种 分 区 类 型 是 RANGE 分 区 ， 也 是 最 常用 的 一 种 分 
区 类 型 。 下 面 的 CREATE TABLE 语 名 创建 了 一 个 id 列 的 区 间 分 区 表 。 当 
id 小 于 10 时 ， 数据 插入 p0 分 区 。 当 id 大 于 等 于 10 小 于 20 时 ， 数 据 插 入 pl 
分 区 。 








CREATE TABLE t( 
id INT 

)ENGINE=INNDB 

PARTITION BY RANGE(id)( 

PARTITION pO VALUES LESS THAN(10), 
PARTITION pi VALUES LESS THAN(20)); 








查看 表 在 磁盘 上 的 物理 文件 ， 启 用 分 区 之 后 ， 表 不 再 由 一 个 ibd 文 
件 组 成 了 ， 而 是 由 建立 分 区 时 的 各 个 分 区 ibd 文 件 组 成 ， 如 下 面 的 
t#P#p0.ibd, t#P#p1.ibd: 





A apt en ls- E n s 

-1 mysql mysql 8.4K 7 月 31 14:11/usr/local/mysql/data/test2/t.frm 
Spike -1 mysql mysql 28 A^ Bai 14:11/usr/local/mysql/data/test2/t.par 
-rw-rw----1 mysql mysql 96K 7 月 31 14:12/usr/local/mysql/data/test2/t#P#p0. ibd 
wl ri mysql mysql 96K 7 月 31 14:12/usr/local/mysql/data/test2/t#P#p1.ibd 





接 看 插入 如 下 数据 : 





mysql>INSERT INTO t SELECT 9; 
Query OK,1 row affected(0.03 sec) 
Records:1 Duplicates:0 Warnings:0 
mysql>INSERT INTO tSELECT 10; 
Query OK,1 row affected(0.03 sec) 
Records:1 Duplicates:0 Warnings:0 
mysql>INSERT INTO t SELECT 15; 
Query OK,1 row affected(0.03 sec) 
Records:1 Duplicates:0 Warnings:O 





因为 表 t 根 据 列 id 进行 分 区 ， 所 以 数据 是 根据 列 庆 的 值 的 范围 存放 在 
不 同 的 物理 文件 中 的 ， 可 以 通过 查询 Information schemasf 构 下 的 
PARTITIONS 表 来 查看 每 个 分 区 的 具体 信息 : 





mysql>SELECT*FROM information schema.PARTITIONS 
->WHERE table schema-database()AND table name-'t'*G; 


TABLE CATALOG: NULL 
TABLE SCHEMA:test2 
TABLE NAME:t 

PARTITION NAME:pO 
SUBPARTITION NAME:NULL 


PARTITION ORDINAL POSITION:1 
SUBPARTITION ORDINAL POSITION:NULL 
PARTITION METHOD:RANGE 
SUBPARTITION METHOD:NULL 
PARTITION EXPRESSION:id 
SUBPARTITION EXPRESSION:NULL 
PARTITION DESCRIPTION:10 
TABLE ROWS:1 

AVG. ROW LENGTH:16384 

DATA LENGTH:16384 

MAX DATA LENGTH:NULL 

INDEX LENGTH:O 

DATA FREE:0 

CREATE TIME:NULL 

UPDATE TIME:NULL 

CHECK TIME:NULL 

CHECKSUM: NULL 

PARTITION COMMENT: 
NODEGROUP : default 
TABLESPACE NAME: NULL 


TABLE CATALOG: NULL 

TABLE SCHEMA:test2 

TABLE NAME:t 

PARTITION NAME:p1i 
SUBPARTITION NAME:NULL 
PARTITION ORDINAL POSITION:2 
SUBPARTITION ORDINAL POSITION:NULL 
PARTITION METHOD:RANGE 
SUBPARTITION METHOD:NULL 
PARTITION EXPRESSION: id 
SUBPARTITION EXPRESSION:NULL 
PARTITION DESCRIPTION:20 
TABLE ROWS:2 

AVG ROW LENGTH:8192 

DATA LENGTH:16384 

MAX DATA LENGTH:NULL 

INDEX LENGTH:O 

DATA FREE:0O 

CREATE TIME:NULL 

UPDATE TIME:NULL 

CHECK TIME:NULL 

CHECKSUM: NULL 

PARTITION COMMENT: 
NODEGROUP : default 

TABLESPACE NAME:NULL 

2 rows in set(0.00 sec) 





TABLE_ROWS 列 反映 了 每 个 分 区 中 记录 的 数量 。 由 于 之 前 向 表 中 
插入 了 9、10、15 三 条 记录 ， 因 此 可 以 看 到 ， 当 前 分 区 p0 中 有 1 条 记录 ， 
分 区 p1 中 有 2 条 记录 。PARTITION_METHOD 表 示 分 区 的 类 型 ， 这 里 显 
示 的 是 RANGE。 


对 于 表 t， 由 于 我 们 定义 了 分 区 ， 因 此 对 于 插入 的 值 应 该 严格 遵守 
分 区 的 定义 ， 当 插入 一 个 不 在 分 区 中 定义 的 值 时 ，MySQL 数 据 库 会 抛 
出 一 个 异常 。 如 下 所 示 ， 我 们 向 表 t 中 插入 30 这 个 值 。 











mysql>INSERT INTO t SELECT 30; 
ERROR 1526(HY000):Table has no partition for value 30 





对 于 上 述 问题 ， 我 们 可 以 对 分 区 添加 一 个 MAXVALUE 值 的 分 区 。 
MAXVALUE 可 以 理解 为 正 无 穷 ， 因 此 所 有 大 于 等 于 20 且 小 于 
MAXVALUE 的 值 别 放 入 p2 分 区 。 











mysql>ALTER TABLE t 

->ADD PARTITION( 

->partition p2 values less than maxvalue); 
Query OK,0 rows affected(0.45 sec) 


Records:0 Duplicates:0 Warnings:O 
mysql>INSERT INTO t SELECT 30; 

Query OK,1 row affected(0.03 sec) 
Records:1 Duplicates:0 Warnings:0 








RANGE 分 区 主要 用 于 日 期 列 的 分 区 ， 例 如 对 于 销售 类 的 表 ， 可 以 
根据 年 来 分 区 存放 销售 记录 ， 如 下 面 的 分 区 表 sales: 





mysql>CREATE TABLE sales( 

->money INT UNSIGNED NOT NULL, 

->date DATETIME 

- >) ENGINE=INNODB 

->PARTITION by RANGE(YEAR(date) )( 

->PARTITION p2008 VALUE LESS THEN( 2009), 
->PARTITION p2009 VALUE LESS THEN( 2010), 
->PARTITION p2010 VALUE LESS THEN( 2011) 

>); 

Query OK,0 rows affected(0.34 sec) 

mysql>INSERT INTO sales SELECT 100, '2008-01-01'; 
Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:0 

mysql>INSERT INTO sales SELECT 100, '2008-02-01'; 
Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:0 

mysql>INSERT INTO sales SELECT 200, '2008-01-02'; 
Query OK,1 row affected(0.04 sec) 

Records:1 Duplicates:0 Warnings:0 

mysql>INSERT INTO sales SELECT 100, '2009-03-01'; 
Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:0 

mysql>INSERT INTO sales SELECT 200, '2010-03-01'; 
Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:0 








这 样 创 建 的 好 处 是 ， 便 于 对 sales 这 张 表 的 管理 。 如 果 我 们 要 删除 
2008 年 的 数据 ， 不 需 要 执行 DELETE FROM sales WHERE date >='2008- 
01-01'and date<'2009-01-01， 只 需 删除 2008 年 数据 所 在 的 分 区 即 可 : 








mysql>alter table sales drop partition p2008; 
Query OK,0 rows affected(0.18 sec) 
Records:0 Duplicates:0 Warnings:0 





XCFEGUEE IT 3 — 1 4f Kb XE RT EUIS RE, UAT E 
查询 2008 年 整 年 的 销售 额 ， 可 以 这 样 : 





mysql>EXPLAIN PARTITIONS 

->SELECT*FROM sales 

->WHERE date>='2008-01-01'AND date<='2008-12-31'\G; 
JOOOOOOOOOOROOOOOOOHOOIOOOOOOR] | pj CRCOOOOGOROOOOOOOOOIOOOOORROROK 
id:1 

select_type:SIMPLE 

table:sales 

partitions:p2008 

type:ALL 

possible_keys:NULL 

key: NULL 

key_len: NULL 

ref: NULL 

rows:5 

Extra:Using where 

1 row in set(0.00 sec) 





通过 EXPLAIN ”PARTITION 命 令 我 们 可 以 发 现 ， 在 上 述 语句 中 ， 


SQL 优 化 器 只 需要 去 搜索 p2008 这 个 分 区 ， 而 不 会 去 搜索 所 有 的 分 区 
称 为 Partition Pruning 〈 分 区 修剪 ) ， 故 查询 的 速度 得 到 了 大 幅度 的 
提升 。 需 要 注意 的 是 ， 如 果 执 行 下 列 语句 ， 结 果 是 一 样 的， 但 是 优化 占 
的 选择 可 能 又 会 不 同 了 : 














mysql>EXPLAIN PARTITIOENS 
->SELECT*FROM sales 


FOI III IIIT, pulled ee ee e Ree er 
id:1 

select_type:SIMPLE 

table:sales 

partitions: p2008, p2009 

type:ALL 

possible_keys:NULL 

key: NULL 


rows :5 
Extra:Using where 
1 row in set(0.00 sec) 





这 次 条 件 改 为 date 二 '2009-01-01' 而 不 是 date 二 ='2008-12-31' 时 ， 优 化 
器 会 选择 搜索 p2008 和 p2009 两 个 分 区 ， 这 是 我 们 不 希望 看 到 的 。 因 此 对 
于 启用 分 区 ， 应 该 根据 分 区 的 特性 来 编写 最 优 的 SQL 语 句 。 


对 于 sales 这 张 分 区 表 ， 我 曾 看 到 过 为 一 种 分 区 函数 ， 设 计 者 的 原意 
是 按照 每 年 每 月 来 进行 分 区 ， 如 : 





mysql>CREATE TABLE sales( 

->money INT UNSIGNED NOT NULL, 

->date DATETIME 

- >) ENGINE=INNODB 

->PARTITION by RANGE(YEAR(date) *100+MONTH(date) ) ( 
->PARTITION p201001 VALUES LESS THEN(201002), 
->PARTITION p201002 VALUES LESS THEN(201003), 
->PARTITION p201003 VALUES LESS THEN(201004) 


->); 
Query OK,0 rows affected(0.37 sec) 














但 是 在 执行 SQL 语 句 时 开发 人 员 友 现 ， 优 化 费 不 会 根据 分 区 进行 选 
择 ， 即 使 他 们 编写 的 SQL 语 句 已 经 符合 了 分 区 的 要 求 ， 如 : 





mysql>EXPLAIN PARTITIONS 
->SELECT*FROM sales 


OR IK OK IO IK IK IO IK TOK IR IK yy RR RR ROR koe koe ke ee ko eek ke ee 


1 
select_type:SIMPLE 
table:sales 
partitions:p201001, p201002, p201003 
type:ALL 
possible_keys:NULL 
ULL 


Extra:Using where 
1 row in set(0.00 sec) 


ee | 


可 以 看 到 优化 对 分 区 p201001， p201002，p201003 都 进行 了 搜索 。 
产生 这 个 问题 的 主要 原因 是 对 于 RANGE 分 区 的 查询 ， 优 化 器 只 能 对 
YEAR(), TO_DAYS(), TO ou UNIX _TIMESTAMPO 这 类 函 
数 进 行 优 化 选择 ， 因 此 对 于 上 述 的 要 求 ， 需 要 将 分 区 函数 改 为 
TO_DAYS， 如 : 











mysql>CREATE TABLE sales( 

->money INT UNSIGNED NOT NULL, 

->date DATETO,E 

- >) ENGINE=INNODB 

->PARTITION by range(TO- DAYS(date) ) ( 
->PARTITION p2010 

->VALUES LESS THEN CTO DAYS('2010-02-01')), 
->PARTITION p2010 

->VALUES LESS THEN CTO DAYS('2010-03-01')), 
->PARTITION p2010 

->VALUES LESS ane DAYS('2010-04-01')) 


->); 
Query OK,0 rows affected(0.36 sec) 





XXI BESETTAH KERA, UU s n] DR BY AT DX HEAT A A 
qs 





mysql-EXPLAIN es e 
->SELECT*FROM sale 
->WHERE date>= cree 01-01' qua (porq '2010-01-31'\G; 
OO ORO GEORGIO GEORGIO OR OR] POE ORO OE KE KKK KKE I IG I I I I I a k 
id:i 
select type:SIMPLE 
table:sales 
Pel E p201001 
type:A 
possible. keys:NULL 


rows:4 
Extra:Using where 
1 row in set(0.00 sec) 





2.LIST 分 区 


LIST 分 区 和 RANGE 分 区 非常 相似 ， 只 是 分 区 列 的 值 是 离散 的 ， 而 
非 连续 的 。 如 : 





mysql> CREATE TABLE t( 


2 re INNODB 

->PARTITION BY LIST(b)( 
->PARTITION pO VALUES IN(1,3,5,7,9), 
->PARTITION pi VALUES IN(0,2,4,6,8) 


>); 
Query OK,0 rows affected(0.26 sec) 





不 同 于 RANGE 分 区 中 定义 的 VALUES LESS THAN 语 句 ，LIST 分 区 
使 用 VALUES IN。 因为 每 个 分 区 的 值 是 离散 的 ， 因 此 只 能 定义 值 。 例 
如 辐 表 t 中 插入 一 些 数据 : 


uM MáI 


mysql>INSERT INTO t SELECT 1,1; 

Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:0 

mysql>INSERT INTO t SELECT 1,2; 

Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:O 

mysql>INSERT INTO t SELECT 1,3; 

Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:O 

mysql>INSERT INTO t SELECT 1,4; 

Query OK,1 row affected(0.03 sec) 

Records:1 Duplicates:0 Warnings:0 

mysql>SELECT table_name, partition_name, table_rows 
->FROM information_schema.PARTITIONS 

->WHERE table_name='t'AND table_schema=DATABASE()\G; 
FIO TO IO ITO TOI 1.TOW* *XXOOOOOOOOOOOOOGOOOOORR 
table name:t 

partition name:p9 

table rows:2 


table name:t 

partition name:pi 
table rows:2 

2 rows in set(0.00 sec) 





如 果 插 入 的 值 不 在 分 区 的 定义 中 ，MySQL 数 据 库 同样 会 抛 出 寞 
常 : 





mysql>INSERT INTO t SELECT 1,10; 
ERROR 1526(HY000):Table has no partition for value 10 





另外 ， 在 用 INSERT 插 入 多 个 行 数据 的 过 程 中 遇 到 分 区 未 定义 的 值 
时 ，MyISAM 和 InnoDB 存 储 引擎 的 处 理 完全 不 同 。MyISAM 引 擎 会 将 之 
前 的 行 数据 都 插入 ， 但 之 后 的 数据 不 会 被 插入 。 而 InnoDB 人 存储 引擎 将 
因此 没有 任何 数据 插入 。 先 对 MyYISAM 存 储 引擎 进行 
TEN H: 





mysql>CRATE TABLE t( 
->a INT 


i 
->b INT)ENGINE-MyISAM 

->PARTITION BY LIST(b)( 

->PARTITION pO VALUES IN(1,3,5,7,9), 
->PARTITION pi VALUES IN(0,2,4,6,8) 


->); 

Query OK,0 rows affected(0.05 sec) 

mysql>INSERT INTO t VALUES(1, 2), (2, 4), (6,10), (5,3); 
ERROR 1526(HY000):Table has no partition for value 10 
mysql>SELECT*FROM t; 

+------ +------ + 


2 rows in set(0.00 sec) 





可 以 看 到 (6, 10) . (5, 3) 记录 的 插入 没有 成 功 ， 但 是 之 前 的 
(1, 2), (2, 4) 记录 都 已 经 插入 成 功 了 。 而 对 于 同一 张 表 ， 存 储 引 
擎 换 成 nnoDB， 则 结果 完全 不 同 : 








mysql>TRUNCATE TABLE t; 


Query OK,2 rows affected(0.00 sec) 
mysql>ALTER TABLE t ENGINE-InnoDB; 
Quer K,0 rows affected(0.25 sec) 

Records:0 Duplicates: ings: 

mysql>INSERT INTO t VALUES(1, 2), (2, 4), (6,10), (5,3); 
ERROR 1526(HY000):Table has no partition for value 10 
mysql>SELECT*FROM t; 


Empty set(0.00 sec) 











可 以 看 到 同样 在 插入 “6，10) 记录 时 报错 ， 但 是 没有 任何 一 条 记 
录 被 插入 到 表 t 中 。 因 此 在 使 用 分 区 时 ， 也 需要 对 不 同 存储 引擎 文 持 的 
事务 特性 进行 考虑 。 


3.HASH 分 区 


HASH 分 区 的 目的 是 将 数据 均匀 地 分 布 到 预先 定义 的 各 个 分 区 中 ， 
保证 各 分 区 的 数据 数量 大 致 都 是 一 样 的 。 在 RANGE 和 LIST 分 区 中 ， 必 
须 明确 指定 一 个 给 定 的 列 值 或 列 值 集合 应 该 保存 在 哪个 分 区 中 ， 而 在 

HASH 分 区 中 ，MySQL 自 动 完 成 这 些 工作 ， 用 户 所 要 做 的 只 是 基于 将 要 
进行 哈 希 分 区 的 列 值 指定 一 个 列 值 或 表达 式 ， 以 及 指定 被 分 区 的 表 将 要 
被 分 割 成 的 分 区 数量 。 


要 使 用 HASH 分 区 来 分 割 一 个 表 ， 要 在 CREATE TABLE 语 句 上 添加 
一 个 “PARTITION BY HASH (expr) ” 子 句 ， 其 中 “expr”* 是 一 个 返回 一 
个 整数 的 表达 式 。 它 可 以 仅仅 是 字段 类 型 为 MySQL 整 型 的 列 名 。 此 
外 ， 用 户 很 可 能 需要 在 后 面 再 添加 一 个 "PARTITIONS num’), HP 
num 是 一 个 非 负 的 整数 ， 它 表示 表 将 要 被 分 割 成 分 区 的 数量 。 如 果 没 有 
包括 一 个 PARTITIONS 子 句 ， 那 么 分 区 的 数量 将 默认 为 1。 


下 面 的 例子 创建 了 一 个 HASH 分 区 的 表 t， 分 区 按 日 期 列 b 进 行 : 

















CREATE TABLE t_hash( 
a INT 


b DATETIME 

)ENGINE-InnoDB 

PARTITION BY HASH(YEAR(b)) 
PARTITIONS 4; 





如 果 插 入 一 个 列 b 为 2010-04-01 的 记录 到 表 t_hash 中 ， 那 么 保存 该 条 
记录 的 分 区 如 下 : 





MOD(YEAR( '2010-04-01'), 4) 
=MOD(2010, 4) 
=2 








因此 记录 会 放 入 分 区 p2 中 ， 我 们 可 以 按 如 下 方法 来 验证 : 


V —ÓáI 


mysql>INSERT INTO t hash SELECT 1,'2010-04-01'; 

Query OK,1 row affected(0.04 sec) 

Records:1 Duplicates:0 Warnings:O 

mysql>SELECT table name,partition name,table rows 

- >FROM information schema.PARTITIONS 

-二 WHERE table schema-DATABASE()AND table name-'t hash'*G; 
KAKKEKKEKKEKKEKKEKKEKKEKKEKJ pp eoe oko olor 
table name:t hash 

partition name:p9 

table rows:0 


XOOROROIOROEORCEOIOEOROIOROIOEOROORGEORGRORGROK 2. FOW* E OOOOOOOOIOOOOOOOOOOOORR 
table name:t hash 

partition name:pi 

table rows:0 

FOI TIO TOTO IOI TO TO IOI 3. OW E ROOOOOOOOOOOOOOOOOORR 
table name:t hash 

partition name:p2 

table rows:1 

ITT IIT IRI PT 


table_name:t_hash 
partition_name:p3 
table_rows:0 

4 rows in set(0.00 sec) 





可 以 看 到 p2 分 区 有 1 条 记录 。 当 然 这 个 例子 中 也 许 并 不 能 把 数据 均 
勾 地 分 布 到 各 个 分 区 中 去 ， 因 为 分 区 是 按照 YEAR 函 数 进行 的 ， 而 这 个 
值 本 身 可 是 离散 的 。 如 果 对 于 连续 的 值 进行 HASH 分 区 ， 如 自 增 长 的 主 
键 ， 则 可 以 较 好 地 将 数据 进行 平均 分 布 。 


MVySQL 数 据 库 还 支持 一 种 称 为 LINEAR HASH 的 分 区 ， 它 使 用 一 个 
更 加 复杂 的 算法 来 确定 新 行 插入 到 已 经 分 区 的 表 中 的 位 置 。 它 的 语法 和 
HASH 分 区 的 语法 相似 ， 只 是 将 关键 字 HASH 改 为 LINEAR HASH。 下 面 
创建 一 个 LINEAR HASH 的 分 区 表 t_linear_hash， 它 和 之 前 的 表 t_hash 相 
似 ， 只 是 分 区 类 型 不 同 。 














CREATE TABLE t linear hash( 
a INT 


A 
b DATETIME 

)ENGINE-InnoDB 

PARTITION BY LINEAR HASH(YEAR(b)) 
PARTITIONS 4; 





同样 插入 '2010-04-01' 的 记录 ， 这 次 MySQL 数 据 库 根据 以 下 的 方法 
来 进行 分 区 的 判断 : 


口 取 大 于 分 区 数量 4 的 下 一 个 2 的 峰值 Y，V=POWER(2， 
CEILING(LOG(2, num))-4; 





Ore] XX N=YEAR('2010-04-01') & (V-1)=2. 


虽然 还 是 在 分 区 P2， 但 是 计算 的 方法 和 之 前 的 HASH 分 区 完全 不 
同 ， 接 着 进行 插入 实际 数据 的 验证 : 











mysql>INSERT INTO t linear hash SELECT 1,'2010-04-01'; 
Query OK,1 row affected(0.02 sec) 

Records:1 Duplicates:0 Warnings:0 

mysql>SELECT table_name, partition_name, table_rows 
->FROM information_schema.PARTITIONS 

->WHERE table schema-DATABASE() 

->AND table name-'t linear hash'*6; 

GO OE ROEROE RC IO OE ITI OR ROG AR IR 1. TOW *XOOOODOOODIOOOOOOOOOORR 
table name:t linear hash 

partition name:p9 

table rows:0 


FIT TIT IOI TOR IR IK I STOWE I IO II IR I II KK 
table name:t linear hash 

partition name:pi 

table rows:0 

FIT TOTTI IOI TO IO IO I BOWE II III II RE 
table name:t linear hash 

partition name:p2 

table rows:1 

FEI ICICI IOI E E ICICI RTO II I a G. OW 2G ICI II CII I AOR 


table name:t linear hash 
partition name:p3 

table rows:6 

4 rows in set(0.01 sec) 





LINEAR HASH 分 区 的 优点 在 于 ， 增 加 、 删 除 、 合 并 和 拆 分 分 区 将 
变 得 更 加 快捷 ， 这 有 利于 处 理 含 有 大 量 数 据 的 表 。 它 的 缺点 在 于 ， 与 使 
ee 各 个 分 区 间 数 据 的 分 布 可 能 不 大 均 
衡 。 


4.KEY 分 区 


KEY 分 区 和 HASH 分 区 相似 ， 不 同 之 处 在 于 HASH 分 区 使 用 用 户 定 
义 的 函数 进行 分 区 ，KEY 分 区 使 用 MySQL 数 据 库 提供 的 函数 进行 分 
区 。 对 于 NDB Cluster 引 擎 ，MySQL 数 据 库 使 用 MD5 函 数 来 分 区 ; 对 于 
其 他 存储 引擎 ，MySQL 数 据 库 使 用 其 内 部 的 哈 希 图 数 ， 这 些 函 数 基于 
与 PASSWORD() 一 样 的 运算 法 则 。 如 : 





mysql>CREATE TABLE t_key( 
->a INT 


->b DATETIME)ENGINE-InnoDB 
->PARTITION BY KEY(b) 
->PARTITIONS 4; 

Query OK,0 rows affected(0.43 sec) 





在 KEY 分 区 中 使 用 关键 字 LINEAR 和 在 HASH 分 区 中 使 用 具有 同样 
的 效果 ， 分 区 的 编号 是 通过 2 的 需 〈powers-of-two) 算法 得 到 的 ， 而 不 
是 通过 模 数 算法 。 


5.COLUMNS 分 区 














在 前 面 介绍 的 RANGE、LIST、HASH 和 KEY 这 四 种 分 区 中 ， 分 区 
的 条 件 是 :数据 必须 是 整 型 (interger) ， 如 果 不 是 整 型 ， 那 应 该 需要 通 
过 函数 将 其 转化 为 整 型 ， 如 YEAR()，TO_DAYS()，MONTH( 等 函数 。 


MySQL5.5 版 本 开始 文 持 COLUMNS 分 区 ， 可 视 为 RANGE 分 区 和 LIST 分 
区 的 一 种 进化 。COLUMNS 分 区 可 以 直接 使 用 非 整 型 的 数据 进行 分 区 ， 
分 区 根据 类 型 直接 比较 而 得 ， 不 需要 转化 为 整 型 。 此 外 ， 
RANGECOLUMNS 分 区 可 以 对 多 个 列 的 值 进行 分 区 。 


COLUMNS 分 区 支持 以 下 的 数据 类 型 . 


口 所 有 的 整 型 类 型 ， 如 INT、SMALLINT、TINYINT、BIGINT。 
FLOAT 和 DECIMAL 则 不 予 支持 。 


口 日 期 类 型 ， 如 DATE 和 DATETIME。 其 余 的 日 期 类 型 不 予 支 持 。 


口 字 符 串 类 型 ， 如 CHAR、VARCHAR、BINARY 和 和 
VARBINARY。BLOB 和 TEXT 类 型 不 予 支持 。 


对 于 日 期 类 型 的 分 区 ， 我 们 不 再 需要 YEAR0 和 TO_DAYSO 函 数 
了 ， 而 直接 可 以 使 用 COLUMNS， 如 : 














CREATE TABLE t_columns_range( 
INT, 


b DATETIME 

) ENGINE=INNODB 

PARTITION BY RANGE COLUMNS(B) ( 

PARTITION pO VALUES LESS THAN('2009-01-01'), 

PARTITION pi VALUES LESS THAN('2010-01-01') 
i 








EPEn A BREH FIT ER RIA EXE s 





CREATE TABLE customers_1( 
first_name VARCHAR(25), 
last_name VARCHAR(25), 
street_1 VARCHAR(30), 
street_2 VARCHAR(30), 
city VARCHAR(15), 

renewal DATE 

) 


PARTITION BY LIST COLUMNS(city)( 
PARTITION pRegion_1 
VALUES IN('Oskarshamn', 'Hógsby', 'Mónsterás'), 
PARTITION pRegion 2 
VALUES IN(' Mente 'Hultsfred', 'Vástervik'), 
PARTITION pRegion 3 
VALUES IN('Nássjó', 'Eksj6', 'Vetlanda'), 
PARTITION pRegion . 4 
VALUES IN('Uppvidinge', 'Alvesta', 'Váxjo') 

i 





对 于 RANGE COLUMNS 分 区 ， 可 以 使 用 多 个 列 进行 分 区 ， 如 : 





CREATE TABLE rcx( 
a INT, 


b INT, 
c CHAR(3), 


d INT 

)Engine-InnoDB 

PARTITION BY RANGE COLUMNS(a, d, c)( 

PARTITION pg VALUES LESS THAN(5,10,'ggg'), 

PARTITION pi VALUES LESS THAN(10,20, 'mmmm'), 

PARTITION p2 VALUES LESS THAN(15,30, 'sss'), 

PARTITION p3 VALUES LESS THAN(MAXVALUE, MAXVALUE, MAXVALUE ) 
); 





MySQL5.5 开 始 文 持 COLUMNS 分 区 ， 对 于 之 前 的 RANGE 和 LIST 分 
区 ， 用 户 可 以 用 RANGE COLUMNS 和 LIST COLUMNS 分 区 进行 很 好 的 
AS. 


4.8.5 本 从 区 


子 分 区 Csubpartitioning) 是 在 分 区 的 基础 上 再 进行 分 区 ， 有 时 也 称 
这 种 分 区 为 复合 分 区 Ccomposite partitioning) 。MySQL 数 据 库 允许 在 
RANGE 和 LIST 的 分 区 上 再 进行 HASH 或 KEY 的 子 分 区 ， 如 : 





mysql>CREATE TABLE ts(a INT,b DATE)engine=innodb 

->PARTITION BY RANGE(YEAR(b) ) 

-—SUBPARTITION BY HASH(TO DAYS(b)) 

->SUBPARTITIONS 2( 

->PARTITION pO VALUES LESS THAN(1990), 

->PARTITION pi VALUES LESS THAN(2000), 

->PARTITION p2 VALUES LESS THAN MAXVALUE 

->); 

Query OK,0 rows affected(0.01 sec) 

mysql>system ls-lh/usr/local/mysql/data/test2/ts* 

-rw-rw----1 mysql mysql 8.4K Aug 1 15:50/usr/local/mysql/data/test2/ts.frm 

-rw-rw----1 mysql mysql 96 Aug 1 15:50/usr/local/mysql/data/test2/ts.par 

-rw-rw----1 mysql mysql 96K Aug 1 15:50/usr/local/mysql/data/test2/ts#P#pO#SP#pOspO. ibd 
-rw-rw----1 mysql mysql 96K Aug 1 15:50/usr/local/mysql/data/test2/ts#P#pO#SP#pOsp1. ibd 
-rw-rw----1 mysql mysql 96K Aug 1 15:50/usr/local/mysql/data/test2/ts#P#p1#SP#p1ispO0. ibd 
-rw-rw----1 mysql mysql 96K Aug 1 15:50/usr/local/mysql/data/test2/ 
ts#P#p1#SP#p1sp1.ibd 

-rw-rw----1 mysql mysql 96K Aug 1 15:50/usr/local/mysql/data/test2/ts#P#p2#SP#p2spO0. ibd 
-rw-rw----1 mysql mysql 96K Aug 1 15:50/usr/local/mysql/data/test2/ts#P#p2#SP#p2sp1.ibd 





表 ts 先 根据 b 列 进行 了 RANGE 分 区 ， 然 后 又 进行 了 一 次 HASH 分 
区 ， 所 以 分 区 的 数量 应 该 为 〈3x2=) 6 个 ， 这 通过 查看 物理 磁盘 上 的 文 
件 也 可 以 得 到 证 实 。 我 们 也 可 以 通过 使 用 SUBPARTITION 语 法 来 显 式 
地 指出 各 个 子 分 区 的 名 字 ， 例 如 对 上 述 的 ts 表 同 样 可 以 这 样 : 





mysql>CREATE TABLE ts(a INT,b DATE) 
->PARTITION BY RANGE(YEAR(b)) 
->SUBPARTITION BY HASH(TO_DAYS(b))( 
->PARTITION pO VALUES LESS THAN(1990)( 
->SUBPARTITION sO, 

->SUBPARTITION si 

=>): 

->PARTITION pi VALUES LESS THAN(2000)( 
->SUBPARTITION s2, 

->SUBPARTITION s3 

Um), 

->PARTITION p2 VALUES LESS THAN MAXVALUE( 
->SUBPARTITION s4, 

->SUBPARTITION s5 

->) 


->); 
Query OK,0 rows affected(0.00 sec) 














子 分 区 的 建立 需要 注意 以 下 几 个 问题 : 
口 每 个 子 分 区 的 数量 必须 相同 。 
口 要 在 一 个 分 区 表 的 任何 分 区 上 使 用 SUBPARTITION 来 明确 定义 


就 必须 定义 所 有 的 子 分 区 。 因 此 下 面 的 创建 语句 是 错误 
A] 




















子 





mySql- CREATE TABLE ts(a INT,b DATE) 


-— PARTITION BY 
- >SUBPARTITION 
->PARTITION pO 
- >SUBPARTITION 
- >SUBPARTITION 
->), 
->PARTITION pi 
->PARTITION p2 
- >SUBPARTITION 
- >SUBPARTITION 
a >) 

->)i 


ERROR 1064(42000):Wrong number of subpartitions defined,mismatch with previous setting near' 
PARTITION p2 VALUES LESS THAN MAXVALUE( 


SUBPARTITION s2, 
SUBPARTITION s3 


) 
) "at line 8 


口 每 个 SUBPARTITION 子 句 必 须 包 括 子 分 区 的 一 个 名 字 。 


口子 分 区 的 名 字 必 须 是 唯一 的 。 因 此 下 面 的 创建 语句 是 错误 的 


mySql- CREATE TABLE ts(a INT,b DATE) 


->PARTITION BY 
- >SUBPARTITION 
->PARTITION pg 
- >SUBPARTITION 
- >SUBPARTITION 
->), 

->PARTITION pi 
- >SUBPARTITION 
- >SUBPARTITION 
->), 

->PARTITION p2 
- >SUBPARTITION 
- >SUBPARTITION 
->) 

->)i 


ERROR 1517(HY000):Duplicate partition name sO 


Fay X nI UA PAE, TES CS OR c DR] OP 90 MAER 
假设 有 6 个 磁极， 分别 为 /disk0、/disk1、/disk2 等 。 现 在 考虑 下 面 的 例 


mysql>CREATE TABLE ts(a INT,b DATE)ENGINE-MYISAM 


->PARTITION BY 


->SUBPARTITION BY HASH(TO DAYS(b))( 
->PARTITION pO VALUES LESS THAN(2000)( 


- >SUBPARTITION 


RANGE ( YEAR(b) ) 


BY HASH(TO_DAYS(b)) ( 
VALUES LESS THAN(1990)( 


so, 
si 


VALUES LESS THAN(2000), 
VALUES LESS THAN MAXVALUE( 


s2, 
s3 


RANGE ( YEAR(b) ) 


BY HASH(TO_DAYS(b)) ( 
VALUES LESS THAN(1990)( 


so, 
s1 


VALUES LESS THAN(2000)( 


sO, 
s1 


VALUES LESS THAN MAXVALUE( 


sO, 
s1 


RANGE ( YEAR(b) ) 


sO 


->DATA DIRECTORY-'/disk0/data' 


->INDEX DIRECTORY-'/disk0/idx', 


- >SUBPARTITION 


s1 


->DATA DIRECTORY='/disk1/data' 
->INDEX DIRECTORY='/disk1/idx' 


->), 


->PARTITION pi VALUES LESS THAN(2010)( 


- >SUBPARTITION 


s2 


->DATA DIRECTORY-'/disk2/data' 


->INDEX DIRECTORY-'/disk2/idx', 


- >SUBPARTITION 


s3 


->DATA DIRECTORY-'/disk3/data' 
->INDEX DIRECTORY-'/disk3/idx' 


->), 


->PARTITION p2 VALUES LESS THAN MAXVALUE( 


- >SUBPARTITION 


s4 


->DATA DIRECTORY='/disk4/data' 


->INDEX DIRECTORY-'/disk4/idx', 


- >SUBPARTITION 


s5 





->DATA DIRECTORY='/disk5/data' 
->INDEX DIRECTORY='/disk5/idx' 


aN 


Query OK,0 rows affected(0.02 sec) 





o 





由 于 InnoDB 存 储 引 擎 使 用 表 空 间 上 自动 地 进行 数据 和 索引 的 管理 ， 
因此 会 忽略 DATA DIRECTORY 和 INDEX DIRECTORY 语 法 ， 因 此 上 述 


的 分 区 表 的 数据 和 索引 文件 分 开放 置 对 其 是 无 效 的 : 





mysql>CREATE TABLE ts(a INT,b DATE)engine=innodb 
->PARTITION BY RANGE(YEAR(b) ) 

-—SUBPARTITION BY HASH(TO_DAYS(b) )( 

->PARTITION pO VALUES LESS THAN(2000)( 
->SUBPARTITION sO 

->DATA DIRECTORY-'/disk0/data' 

->INDEX DIRECTORY-'/disk0/idx', 

->SUBPARTITION s1 
->DATA DIRECTORY-'/diski/data' 
->INDEX DIRECTORY-'/diski/idx' 
->), 
->PARTITION p1 VALUES LESS THAN(2010)( 
->SUBPARTITION s2 
->DATA DIRECTORY='/disk2/data' 
->INDEX DIRECTORY-'/disk2/idx', 
->SUBPARTITION s3 
->DATA DIRECTORY='/disk3/data' 
->INDEX DIRECTORY='/disk3/idx' 
->), 
->PARTITION p2 VALUES LESS THAN MAXVALUE( 
->SUBPARTITION s4 
->DATA DIRECTORY='/disk4/data' 
->INDEX DIRECTORY='/disk4/idx', 
->SUBPARTITION s5 
->DATA DIRECTORY='/disk5/data' 
->INDEX DIRECTORY='/disk5/idx' 





->); 

Query OK,0 rows affected(0.02 sec) 

mysql>system ls-lh/usr/local/mysql/data/test2/ts* 

-rw-rw----1 mysql mysql 8.4K Aug 1 16:24/usr/local/mysql/data/test2/ts.frm 
-rw-rw----1 mysql mysql 80 Aug 1 16:24/usr/local/mysql/data/test2/ts.par 

-rw-rw----1 mysql mysql 96K Aug 16:25/usr/local/mysql/data/test2/ts#P#pO0#SP#SsO0. ibd 
-rw-rw----1 mysql mysql 96K Aug 16:25/usr/local/mysql/data/test2/tssP4pOZSPZs1.ibd 
-rw-rw----1 mysql mysql 96K Aug 16:25/usr/local/mysql/data/test2/ts#P#p1#SP#s2. ibd 
-rw-rw----1 mysql mysql 96K Aug 16:25/usr/local/mysql/data/test2/ts#P#p1#SP#s3. ibd 
-rw-rw----1 mysql mysql 96K Aug 16:25/usr/local/mysql/data/test2/ts#P#p2#SP#s4. ibd 
-rw-rw----1 mysql mysql 96K Aug 16:25/usr/local/mysql/data/test2/ts#P#p2#SP#s5. ibd 


|PpBHHHH 


| | 


4.8.4 分 区 中 的 NULL 值 


MySQL 数 据 库 允 许 对 NULL 值 做 分 区 ， 但 是 处 理 的 方法 与 其 他 数据 
库 可 能 完全 不 同 。MYSQL 数 据 库 的 分 区 总 是 视 NULL 值 视 小 于 任何 的 一 
个 非 NULL 值 ， 这 和 MySQL 数据 库 中 处 理 NULL 值 的 ORDER BY 操作 是 
xn Lu mum MySQL 数 据 库 对 于 NULL 值 的 处 理 

是 各 不 相同 。 


对 于 RANGE 分 区 ， 如 果 向 分 区 列 插入 了 NULL 值 ， 则 MySQL 数 据 
库 会 将 该 值 放 入 最 左边 的 分 区 。 例 如 : 





mysql>CREATE TABLE t range( 
->a INT 


7 
->b INT)ENGINE-InnoDB 

->PARTITION BY RANGE(b)( 

->PARTITION pO VALUES LESS THAN(10), 
->PARTITION pi VALUES LESS THAN(20), 
->PARTITION p2 VALUES LESS THAN MAXVALUE 


>); 
Query OK,0 rows affected(0.01 sec) 





接着 向 表 中 插入 OD, (1,NULL) 两 条 数据 ， 并 观察 每 个 分 区 
中 记录 的 数量 : 





mysql>INSERT INTO t range SELECT 1,1; 
Query OK,1 row affected(0.00 sec) 
Records:1 Duplicates:0 Warnings:O 

mysql INSERT INTO t range SELECT 1,NULL; 
Query OK,1 row affected(0.00 sec) 
Records: 1 Duplicates:0 Warnings:0 
mysql>SELECT*FROM t_range\G; 


3k IR KOK IK IR TOK KOR KK dee de e 1.TOW* EE RRR RRR RRO IR K H K 
a:1 
Kk KR k ek IO IR koe ke ke eek dee de ke 2. lOW* EERE RR IO ORO ROIG IO ROIG ROG 
a:i 


2 rows in set(0.00 sec) 

mysql>SELECT table_name, partition_name, table_rows 

->FROM information_schema.PARTITIONS 

->WHERE table schema-DATABASE()AND table_name='t_range'\G; 
FOI IC TTT IT ITT TICE, pyp E K RK K A K IIR EAE A E Um 
table_name:t_range 

partition name:p9 

table rows:2 


GORGE ROEROOROROEOROOREORRORGROK STOWE III III II IO II RE 
table name:t range 

partition name:pi 

table rows:0 

FE e HE HE HEFE TOI ITO ITO RTO III I POW III ICI III I III Ok 


table name:t range 
partition name:p2 

table rows:0 

3 rows in set(0.00 sec) 





可 以 看 到 两 条 数据 都 放 入 了 p0 分 区 ， 也 就 是 说 明了 RANGE 分 区 
下 ，NULL 值 会 放 入 最 左边 的 分 区 中 。 男 外 需要 注意 的 是 ， 如 果 删 除 p0 
这 个 分 区 ， 删 除 的 将 是 小 于 10 的 记录 ， 并 且 还 有 NULL 值 的 记录 ， 这 点 





非常 重要 : 





mysql>ALTER TABLE t range DROP PARTITION pO; 
Query OK,0 rows affected(0.01 sec) 

Records:0 Duplicates:0 Warnings:0 
mysql>SELECT*FROM t range; 

Empty set(0.00 sec) 





在 LIST 分 区 下 要 使 用 NULL 值 ， 则 必须 显 式 地 指出 哪个 分 区 中 放 入 
NULL 值 ， 否 则 会 报错 ， 如 : 





mysql>CREATE TABLE t list( 

->a INT, 

->b INT)ENGINE=INNODB 

->PARTITION BY LIST(b)( 
->PARTITION pO VALUES IN(1,3,5,7,9) 
->PARTITION pi VALUES IN(0,2,4,6,8) 
); 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO t list SELECT 1,NULL; 

ERROR 1526(HY000):Table has no partition for value NULL 


L 





知 p0 分 区 允许 NULL 值 ， 则 插入 不 会 报错 : 





mysql>CREATE TABLE t list( 

->a INT, 

->b INT)ENGINE=INNODB 

->PARTITION BY LIST(b)( 
->PARTITION pO VALUES IN(1,3,5,7,9, 
->PARTITION pi VALUES IN(0,2,4,6,8) 
) ; 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO t list SELECT 1,NULL; 

Query OK,1 row affected(0.00 sec) 

Records:1 Duplicates:0 Warnings:O 

mysql>SELECT table name,partition name,table rows 

->FROM information schema.PARTITIONS 

-二 WHERE table schema-DATABASE()AND table name-'t list'*G; 
JOOOOOOOOOOOOODOOOOOOOOOOOR] | pj COOOOCOOOIOOOOOOOOOOOAOORORO 
table name:t list 

partition name:p9 

table rows:1 
JOOOOOOOIOOOOROOOOOOOOOOOOERK D ej FICCI II ICICI III III II Ie 
table_name:t_list 

partition_name:p1 

table_rows:0 

2 rows in set(0.00 sec) 


NULL), 





HASH 和 KEY 分 区 对 于 NULL 的 处 理 方式 和 RANGE 分 区 、LIST 分 区 
不 一 样 。 任 何 分 区 函数 都 会 将 含有 NULEL 值 的 记录 返回 为 0。 如 : 





mysql>CREATE TABLE t hash( 

->a INT, 

->b INT)ENGINE-InnoDB 

->PARTITION BY HASH(b) 

-— PARTITIONS 4; 

Query OK,0 rows affected(0.00 sec) 

mysql>INSERT INTO t hash SELECT 1,0; 

Query OK,1 row affected(0.00 sec) 

Records:1 Duplicates:0 Warnings:O 

mysql>INSERT INTO t hash SELECT 1,NULL; 

Query OK,1 row affected(0.01 sec) 

Records:1 Duplicates:0 Warnings:O 

mysql>SELECT table name,partition name,table rows 
->FROM information schema.PARTITIONS 

->WHERE table schema-DATABASE()AND table name-'t hash'*G; 


AO RIO ROO IO RO ROO RO ROO GG] py Re Ro e RO RR I e RO Re Re 


table name:t hash 

partition name:p9 

table rows:2 
JOOOOOOIOOCOOOOOOOOO OGGI D | pj FGI II GIGI III III III Ie 
table name:t hash 

partition name:pi 

table rows:0 
JOOOOOOIOOOOOOOOOOOOOOOOOERK | p IGG GIGI III IIIA II Ie 
table name:t hash 

partition name:p2 

table rows:0 
JOOOOOOOOODOOOOOOOOOOOOOOOOR AI ej IIIS ICICI III III III Ie 
table name:t hash 

partition name:p3 

table rows:0 

4 rows in set(0.00 sec) 


和 


4.85 “分 区 和 性 能 


我 常 昕 到 开发 人 员 说 “对 表 做 个 分 区 *， 然 后 数据 库 的 查询 就 会 快 
了 。 这 是 真 的 吗 ? 实际 上 可 能 根本 感觉 不 到 查询 速度 的 提升 ， 其 至 会 发 
现 碍 询 速度 急剧 下 降 。 因 此 ， 在 合理 使 用 分 区 之 前 ， 必 须 了 解 分 区 的 使 
用 环境 。 


数据 库 的 应 用 分 为 两 类 : 一 类 是 OLTP (EREZA) ， 如 
Blog、 电 子 商务 、 网 络 游戏 等 ， 另 一 类 是 OLAP 〈 在 线 分 析 处 理 ) ， 如 
数据 仓库 、 数 据 集 市 。 在 一 个 实际 的 应 用 环境 中 ， 可 能 既 有 OLTP 的 应 
用 ， 也 有 OLAP 的 应 用 。 如 网 络 游戏 中 ， 玩 家 操作 的 游戏 数据 库 应 用 就 
是 OLTP 的 ， 但 是 游戏 厂商 可 能 需要 对 游戏 产生 的 日 志 进 行 分 析 ， 通 过 
分 析 得 到 的 结果 来 更 好 地 服务 于 游戏 ， 预 测 玩家 的 行为 等 ， 而 这 却 是 
OLAP 的 应 用 。 


对 于 OLAP 的 应 用 ， 分 区 的 确 是 可 以 很 好 地 提高 查询 的 性 能 ， 因 为 
OLAP 应 用 大 多 数 查 询 需 要 频繁 地 扫描 一 张 很 大 的 表 。 假 设 有 一 张 1 亿 行 
的 表 ， 其 中 有 一 个 时 间 惟 属性 列 。 用 户 的 查询 需要 从 这 张 表 中 获取 一 年 
的 数据 。 如 果 按 时 间 惟 进行 分 区 ， 则 只 需要 扫 摘 相应 的 分 区 即 可 。 这 束 
是 前 面 介 绍 的 Partition Pruning 技 术 。 


然而 对 于 OLTP 的 应 用 ， 分 区 应 该 非常 小 心 。 在 这 种 应 用 下 ， 通 常 
不 可 能 会 获取 一 张大 表 中 10% 的 数据 ， 大 部 分 都 是 通过 索引 返回 几 条 记 
录 即 可 。 而 根据 B+ 树 索 引 的 原理 可 知 ， 对 于 一 张大 表 ， 一 般 的 B+ 树 震 
要 2 一 3 次 的 磁盘 ID。 因此 B+ 树 可 以 很 好 地 完成 操作 ， 不 需要 分 区 的 帮 
助 ， 并 且 设计 不 好 的 分 区 会 市 来 严重 的 性 能 问题 。 


我 发 现 很 多 开发 团队 会 认为 含有 1000W 行 的 表 是 一 张 非常 巨大 的 
表 ， 所 以 他 们 往往 会 选择 采用 分 区 ， 如 对 主键 做 10 个 HASH 的 分 区 ， 这 
样 每 个 分 区 就 只 有 100W 的 数据 了 ， 因 此 查询 应 该 变 得 更 快 了 如 
SELECT*FROM TABLE WHERE PK=@pk。 但 是 有 没有 考虑 过 这 样 一 
种 情况 : 100wW 和 1000W 行 的 数据 本 身 构 成 的 B+ 树 的 层次 都 是 一 样 的 ， 
可 能 都 是 2 层 。 那 么 上 述 走 主 键 分 区 的 索引 并 不 会 带 来 性 能 的 提高 。 好 
的 ， 如 果 1000W 的 B+ 树 的 高 度 是 3，100W 的 B+ 树 的 高 度 是 2， 那 么 上 述 
按 主键 分 区 的 索引 可 以 避免 1 次 IO， 从 而 提高 查询 的 效率 。 这 没 问 题 ， 
但 是 这 张 表 只 有 主键 索引 ， 没 有 任何 其 他 的 列 需 要 查询 的 。 如 果 还 有 类 





























vy 


似 如 下 的 SQL 语句 : SELECT*FROM TABLE WHERE KEY=@key, iX 
时 对 于 KEY 的 查询 需要 扫描 所 有 的 10 个 分 区 ， 即 使 每 个 分 区 的 查询 开销 
为 2 次 IJO， 则 一 共 需 要 20 次 IO。 而 对 于 原来 单 表 的 设计 ， 对 于 KEY 的 但 
询 只 需要 2 一 3 次 IO。 


接着 来 看 如 下 的 表 Profile， 根 据 主键 ID 进行 了 HASH 分 区 ，HASH 
分 区 的 数量 为 10， 表 Profile 有 接近 1000W 的 数据 : 








mysql>CREATE TABLE'Profile'( 
->'id'int(11)NOT NULL AUTO INCREMENT, 
->'nickname'varchar(20)NOT NULL DEFAULT'', 
->'password'varchar(32)NOT NULL DEFAULT'', 
->'sex'char(1)NOT NULL DEFAULT'', 
->'rdate'date NOT NULL DEFAULT'0000-00-00', 
->PRIMARY KEY('id'), 
->KEY'nickname'('nickname' ) 

- >) ENGINE=InnoDB 

->PARTITION BY HASH(id) 

->PARTITIONS 10; 

Query OK,0 rows affected(1.29 sec) 
mysql>SELECT COUNT(nickname)FROM Profile; 
JOOOOOOOOOOOROOOOOOOOOOOOOOOR 6 Q yy AEGIS III ICICI III III III IE 
count (1):9999248 

1 row in set(1 min 24.62 sec) 





因为 是 根据 HASH 分 区 的 ， 所 以 每 个 区 分 的 记录 数 大 致 是 相同 的 ， 
即 数据 分 布 比较 均 色 : 








mysql>SELECT table name,partition name,table rows 

->FROM information schema.PARTITIONS 

-二 WHERE table schema-DATABASE()AND table name-'Profile'*G; 
JOOOOOOOOOOOOOODOOOOOOOOOOOR] I pj RCOOOOCOOOIOOOOOOOOOOEOORGOR 
table name:Profile 

partition name:p9 

table rows:990703 
JOOOOOOOIOOOOOOOOOOOOOOOOOERK OK pj FIG II ICICI III III II I Ie 
table_name:Profile 

partition_name:p1 

table rows:1086519 
JOOOOOOOIOOOOOOOOOOOOOOOOOERK 6) FSC III III Ie 
table_name:Profile 

partition name:p2 

table rows:976474 
JOOOOOOIOOOOOOOOOOOOOOOOOOOR Ac pj FGI II ICICI III III III Ie 
table_name:Profile 

partition name:p3 

table rows:986937 
JOOOOEOOIOOOOOOOOOOOOOOOOOERK B | p CCOOOOCOOOOOOOOOOIOOOOOOROROK 
table name:Profile 

partition name:p4 

table rows:993667 
JOOOOOOOOOOOROOOOOOOOOOOOOERRG | pj CRCOOOOOOOOOOOOOOOIOOOOORORR 
table name:Profile 

partition name:p5 

table rows:978046 
JOOOOOOOOODOOOOOOOIOOOIOOOOOORT | pj ISIC III III III Ie 
table_name:Profile 

partition name:p6 

table rows:990703 
JOOOOOOOOOOOOOOOOOOOOOOOERK 6 Q yy FICCI II ICICI III III III Ie 
table_name:Profile 

partition name:p7 

table rows:978639 
JOOOOOOIOOOOOOOOOOOOOOOOOERRQ | pj FICCI III ICICI III III II Ie 
table_name:Profile 

partition name:p8 

table rows:1085334 
JOOOOOOOOOOOOOOOOOOOOOOOOOR0 Q, P O $ E CGI III ICICI III I III II I Ie 
table_name:Profile 

partition name:p9 

table rows:982788 

10 rows in set(0.80 sec) 


pLM——M—— Ma 





注意 ”即使 是 根据 目 增 长 主键 进行 的 HASH 分 区 也 不 能 保证 分 区 数 
据 的 均匀 。 因 为 插入 的 自 增 长 ID 并 非 总 是 连续 的 ， 如 果 该 主键 值 因 为 茶 
种 原因 被 回 深 了 ， 则 该 值 将 不 会 再 次 被 自动 使 用 。 


如 果 进 行 主 键 的 查询 ， 可 以 发 现 分 区 的 确 是 有 意义 的 : 








mysql>EXPLAIN PARTITIONS SELECT*FROM Profile WHERE id=1\G; 
FOI FE FEKE EKEK EKK KEK KREK KKG, pp eor 
id:1 

select type:SIMPLE 

table:Profile 

partitions:pi 

type:const 

possible keys:PRIMARY 

key : PRIMARY 

key len:4 

ref:const 

rows:1 

Extra: 

1 row in set(0.00 sec) 








可 以 发 现 只 寻找 了 pl 分 区 ， 但 是 对 于 表 Profile 中 mickname 列 索引 的 
查询 ，EXPLAIN PARTITIONS 则 会 得 到 如 下 的 结 





mysql>EXPLAIN PARTITIONS 

->SELECT*FROM Profile WHERE nickname='david'\G; 
FOI III ————Á—M—————— 
id:1 

select_type:SIMPLE 

table:Profile 

partitions: pO, p1, p2, p3, p4, p5, p6, p7, p8, p9 
type:ref 

possible_keys:nickname 

key:nickname 

key_len:62 

ref:const 

rows:10 

Extra:Using where 

1 row in set(0.00 sec) 





可 以 看 到 ，MySQL 数 据 库 会 搜索 所 有 分 区 ， 因 此 奏 询 速度 上 会 慢 
很 多 ， 比 较 上 述 的 语句 : 


E 





mysql>SELECT*FROM Profile WHERE nickname='david'\G; 

FOI III III IIOP Qi III III IEF 
id:5566 

nickname: david 

password: 3e35d1025659d07ae28e0069ec51ab92 

sex:M 

rdate: 2003-09-20 

1 row in set(1.05 sec) 





上 述 简单 的 索引 查找 语句 竟然 需要 1.05 秒 ， 这 显然 是 因为 查询 需要 
明 历 所 有 分 区 的 关系 ， 实 际 的 IO 执行 了 约 20 一 30 次 。 而 在 未 分 区 的 同样 
结构 和 大 小 的 表 上 ， 执 行 上 述 同样 的 SQL 语句 只 需要 0.26 秒 。 


因此 对 于 使 用 mnoDB 存 储 引 擎 作为 OLTP 应 用 的 表 在 使 用 分 区 时 应 





该 十 分 小 心 ， 设 计时 确认 数据 的 访问 模式 ， 否 则 在 OLTP 应 用 下 分 区 可 
能 不 仅 不 会 带 来 查询 速度 的 提高 ， 反 而 可 能 会 使 你 的 应 用 执行 得 更 慢 。 


4.8.6 (TEX MIA] [X IR] Az HZ 
MySQL 5.6 开 始 支 持 ALTER TABLE...EXCHANGE PARTITION 语 
法 。 该 语句 允许 分 区 或 子 分 区 中 的 数据 与 男 一 个 非 分 区 的 表 中 的 数据 进 
行 交 换 。 如 果 非 分 区 表 中 的 数据 为 衬 ， 那 么 相当 于 将 分 区 中 的 数据 移动 
o 各 分 区 表 中 的 数据 为 空 ， 则 相当 于 将 外 部 表 中 的 数据 导 
| 分 区 中 。 


要 使 用 ALTER TABLE...EXCHANGE PARTITION 语句， 必须 满足 
下 面 的 条 件 : 


口 要 交换 的 表 需 和 分 区 表 有 着 相同 的 表 结构 ， 但 古 表 不 能 含有 分 区 
口 在 非 分 区 表 中 的 数据 必须 在 交换 的 分 区 定义 内 
口 被 交换 的 表 中 不 能 含有 外 键 ， 或 者 其 他 的 表 含 有 对 该 表 的 外 键 引 








用 


口 用 户 除 了 需要 ALTER、INSERT 和 CREATE 权 限 外 ， 还 需要 
DROP 的 权限 


此 外 ， 有 两 个 小 的 细节 需要 注意 : 
口 使 用 该 语句 时 ， 不 会 触发 交换 表 和 被 交换 表 上 的 触发 器 
口 AUTO_INCREMENT 列 将 被 重 置 


m ee 首先 创建 含有 RANGE 分 区 的 表 e， 并 填充 相应 
数据 : 





CREATE TABLE e( 
id INT NOT NULL, 
fname VARCHAR(30), 
lname VARCHAR(30) 
) 
PARTITION BY RANGE(i 
I 
' 
PARTITION p2 VALUES LESS THAN(150), 
PARTITION p3 VALUES LESS THAN(MAXVALUE ) 
7 
INSERT INTO e VALUES 
(1669, "Jim", Smith"), 
(337,"Mary","Jones"), 
" 1 


,"Frank","White"), 
(2005, "Linda", Black"); 





然后 创建 交换 表 e2。 表 e2 的 结构 和 表 e 一 样 ， 但 需要 注意 的 是 表 e2 
不 能 含有 分 区 ; 





mysql>CREATE TABLE e2 LIKE e; 

Query OK,0 rows affected(1.34 sec) 
mysql>ALTER TABLE e2 REMOVE PARTITIONING; 
Query OK,0 rows affected(0.90 sec) 
Records: Duplicates:0 Warnings:0 





过 下 列 语句 观察 分 区 表 中 的 数据 : 





mysql>SELECT PARTITION NAME, TABLE ROWS 
- >FROM INFORMATION =i PARTITIONS 
TERS TABLE | E 


a rows in set(0. BE sec) 





因为 表 e2 中 的 没有 数据 ， 使 用 如 下 语句 将 表 e 的 分 区 p0 中 的 数据 移 
动 到 表 e2 中 : 





mysql>ALTER TABLE e EXCHANGE PARTITION pO WITH TABLE e2; 
Query OK,0 rows affected(0.28 sec) 





这 时 再 观察 表 e 中 分 区 的 数据 ， 可 以 发 现 p0 中 的 数据 已 经 没有 了 。 





mysql>SELECT PARTITION NAME, TABLE_ROWS 
- >FROM INFORMATION oe PARTITIONS 
ee TABLE | hid nl 


P rows in set(0. 6 Sec) 





而 这 时 可 以 在 表 e2 中 观 穴 到 被 移动 的 数据 : 





mysql >SELECT" " FROM e2; 


1 row in set(0.00 sec) 





AG 小结 


读 完 这 一 章 后 ， 和 希望 用 户 对 InnoDB 存 储 引擎 表 有 一 个 更 深刻 的 理 
解 。 在 这 一 章 中 首先 介绍 了 InnoDB 存 储 引 擎 表 总 是 按照 主键 索引 顺序 
进行 存放 的 。 然 后 深入 介绍 了 表 的 物理 实现 (如 行 结构 和 页 结构 )， 这 
一 部 分 有 助 于 用 户 更 进一步 了 解 表 物理 存储 的 底层 。 接 着 介绍 了 和 表 有 
天 的 约束 问题 ，MySQL 数 据 库 通过 约束 来 保证 表 中 数据 的 各 种 完整 
性 ， 其 中 也 提 到 了 有 关 InnoDB 存 储 引 擎 支持 的 外 键 特性 。 之 后 介绍 了 
视图 ， 在 MySQL 数 据 库 中 视图 总 是 虚拟 的 表 ， 本 号 不 支持 物化 视图 。 
o al 《如 触发 器 ) 同样 也 可 以 实现 一 些 简单 的 物化 
视图 的 功能 。 


最 后 部 分 介绍 了 分 区 ，MySQL 数 据 库 文 持 RANGE、LIST、 
HASH、KEY、COLUMNS 人 分区， 并且 可 以 使 用 HASH 或 KEY 来 进行 子 
分 区 。 需 要 注意 的 是 ， 分 区 并 不 总 是 适合 于 OLTP 应 用 ， 用 户 应 该 根据 
自己 的 应 用 好 好 来 规划 自己 的 分 区 设计 。 
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序 的 性 能 可 能 会 受到 影响 。 而 索引 太 少 ， 对 得 询 性 能 又 会 产生 影响 。 要 
找到 一 个 合适 的 平衡 点 ， 这 对 应 用 程序 的 性 能 至 关 重 要 。 


一 些 开发 人 员 总 是 在 事后 才 想 起 添加 索引 一 一 我 一 直 认 为 ， 这 源 于 
一 种 错误 的 开发 模式 。 如 果 知 道 数 据 的 使 用 ， 从 一 开始 就 应 该 在 需要 处 
添加 索引 。 开 发 人 员 往 往 对 于 数据 库 的 使 用 停留 在 应 用 的 层面 ， 比 如 编 
写 SQL 语 句 、 存 储 过 程 之 类 ， 他 们 甚至 可 能 不 知道 索引 的 存在 ， 或 者 认 
为 事后 让 相关 DBA 加 上 即 可 。DBA 往 往 不 够 了 解 业 务 的 数据 流 ， 而 添 
加 索引 需要 通过 监控 大 量 的 SQL 语句 进而 从 中 找到 问题 ， 这 个 步骤 所 需 
的 时 间 肯 定 是 远大 于 初始 添加 索引 所 需要 的 时 间 ， 并 且 可 能 会 遗漏 一 部 
分 的 索引 。 当 然 索 引 也 并 不 是 越 多 越 好 ， 我 曾经 遇 到 这 样 一 个 问题 : 某 
人 台 MySQL 服 务 器 iostat 显 示人 磁盘 使 用 率 一 直 处 于 100%， 经 过 分 析 后 发 现 
是 由 于 开发 人 员 添 加 了 太 多 的 索引 ， 在 删除 一 些 不 必要 的 索引 之 后 ， 磁 
盘 使 用 率 马 上 下 降 为 20%。 可 见 索引 的 添加 也 是 非常 有 技术 含量 的 。 


这 一 章 的 主旨 是 对 mnoDB 存 储 引擎 支持 的 索引 做 一 个 概述 ， 并 对 
索引 内 部 的 机 制 做 一 个 深入 的 解析 ， 通 过 了 解 索引 内 部 构造 来 了 解 哪里 
可 以 使 用 索引 。 本 章 的 风格 和 别 的 有 关 MySQL 的 书 有 所 不 同 ， 更 偏重 
于 索引 内 部 的 实现 和 算法 问题 的 讨论 。 


























5.1 InnoDB4f M 5| SE Z& 5 | EX 
InnoDB 存 储 引 擎 支持 以 下 几 种 常见 的 索引 : 
DB+ 树 索引 
口 全 文 索引 
口 哈 希 索引 


前 面 已 经 提 到 过 ，InnoDB 存 储 引 擎 文 持 的 哈 希 索引 是 上 自 适 应 的 ， 
InnoDB 存 储 引 擎 会 根据 表 的 使 用 情况 上 自动 为 表 生 成 哈 希 索引 ， 不 能 人 
为 干预 是 否 在 一 张 表 中 生成 哈 希 索引 。 


B+ 树 索引 就 是 传统 意义 上 的 索引 ， 这 是 目前 关系 型 数据 库 系 统 中 
查找 最 为 常用 和 最 为 有 效 的 索引 。B+ 树 索引 的 构造 类 似 于 二 叉 树 ， 根 
据 键 值 (Key Value) 快速 找到 数据 。 


注意 ，B+ 树 中 的 B 不 是 代表 二 又 (binary) ， 而 是 代表 平衡 
(balance) 0 Paine 但 是 B+ 树 不 
是 一 个 二 又 树 。 


另 一 个 常常 被 DBA 忽 视 的 问题 是 : B+ 树 索引 并 不 能 找到 一 个 给 定 
键 值 的 具体 行 。B+ 树 索引 能 找到 的 只 是 被 查找 数据 行 所 在 的 页 。 然 后 
oe ee 再 在 内 存 中 进行 查找 ， 节 后 得 到 要 得 找 的 











5.2. ”数据 结构 与 算法 


B+ 树 索 引 是 最 为 第 见 ， 也 是 在 数据 库 中 使 用 最 为 频繁 的 一 种 索 
引 。 在 介绍 该 索引 之 前 先 介 绍 与 之 密切 相关 的 一 些 算法 与 数据 结构 ， 这 
有 助 于 读者 更 好 的 理解 B+ 树 索引 的 工作 方式 。 


5.2.1 ”二 分 查找 法 


二 分 查找 法 (binary search) 也 称 为 折 半 查找 法 ， 用 来 查找 一 组 有 
序 的 记录 数组 中 的 某 一 记录 ， 其 基本 思想 是 : 将 记录 按 有 序 化 (递增 或 
递减 ) 排列 ， 在 查找 过 程 中 采用 跳跃 式 方式 查找 ， 即 先 以 有 序数 列 的 中 
点 位 置 为 比较 对 象 ， 如 果 要 找 的 元 素 值 小 于 该 中 点 元 素 ， 则 将 待 查 序列 
Aa f WA RES. WIKRE, ERR ]N— 








W5, 10. 19. 21. 31. 37. 42. 48. 50. 523x107 3t, HEM 
这 10 个 数 中 查找 48 这 条 记录 ， 其 查找 过 程 如 图 5-1 所 示 。 


3 10.19 21 31 37 42 48 30. 
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31192733245 


| 


3 10.19 21 31 37 42 48 30 dS 





图 53 二 分 查找 法 


从 图 5-1 可 以 看 出 ， 用 了 3 次 就 找到 了 48 这 个 数 。 如 果 是 顺序 查找 ， 
则 需要 8 次 。 因 此 二 分 查找 法 的 效率 比 顺序 查找 法 要 好 【平均 地 来 
说 ) 。 但 如 果 说 查 5 这 条 记录 ， 顺 序 查找 只 需 1 次 ， 而 二 分 查找 法 需要 4 
IR 我 们 来 看 ， 对 于 上 面 10 个 数 来 说 ， 平 均 查 找 次 数 为 
(1+2+3+4+5+6+7+8+9+10) /10=5.5 次 。 而 二 分 查找 法 为 
(4+3+2+4+3+1+4+3+2+3) /10=2.9 次 。 在 最 坏 的 情况 下 ， 顺 序 查 找 的 次 
数 为 10， 而 二 分 查找 的 次 数 为 4。 


二 分 查找 法 的 应 用 极其 广泛 ， 而 且 它 的 思想 易于 理解 。 第 一 个 二 分 
碍 找 法 在 1946 年 就 出 现 了 ， 但 是 第 一 个 完全 正确 的 二 分 查找 法 直到 1962 
年 才 出 现 。 在 前 面 的 章节 中 ， 相 信 读 者 已 经 知道 了 ， 每 页 Page Directory 
中 的 槽 是 按照 主键 的 顺序 存放 的 ， 对 于 某 一 条 有 具体 记录 的 查询 是 通过 对 
Page Directory 进 行 二 分 查找 得 到 的 。 














5.2.2 CSUEHRBURUCT 48] — SUB 


在 介绍 B+ 树 前 ， 需 要 先 了 解 一 下 二 又 奉 找 树 。B+ 树 是 通过 二 又 碍 
找 树 ， 再 由 平衡 二 又 树 ，B 树 演化 而 来 。 相 信和 在 任何 一 本 有 关 数 据 结构 
的 书 中 都 可 以 找到 二 又 碍 找 树 的 音节， 二 又 碍 找 树 是 一 种 经 典 的 数据 结 
构 。 图 5-2 显 示 了 一 柠 二 又 碍 找 树 。 


/ N 
NON 


图 52 二 又 查找 树 


图 5-2 中 的 数字 代表 每 个 节点 的 键 值 ， 在 二 又 查找 树 中 ， 左 子 树 的 
键 值 总 是 小 于 根 的 键 值 ， 右 子 树 的 键 值 总 是 大 于 根 的 键 值 。 因 此 可 以 通 
en E ms 图 5-2 的 二 又 查找 树 经 过 中 序 遍 历 后 
au: 2、3、5、6、7、8。 


对 图 5-2 的 这 棵 二 又 树 进行 查找 ， 如 查 键 值 为 5 的 记录 ， 先 找到 根 ， 
其 键 值 是 6，6 大 于 5， 因 此 查找 6 的 左 子 树 ， 找 到 3; 而 5 大 于 3， 再 找 其 
右 子 树 ， 一 共 找 了 3 次 。 如 果 按 2>、3、5、6、7、8 的 顺序 来 找 同样 需要 3 
次 。 用 同样 的 方法 再 查找 键 值 为 8 的 这 个 记录 ， 这 次 用 了 3 次 查找 ， 而 顺 
序 查 找 需 要 6 次 。 计 算 平 均 查 找 次 数 可 得 : 顺序 查找 的 平均 查找 次 数 为 
(1+2+3+4+5+6) /6=3.3 次 ， 二 叉 碍 找 树 的 平均 查找 次 数 为 

















(34343424241) /6=2.3 次 。 二 叉 碍 找 树 的 平均 查找 速度 比 顺 序 查 找 来 
得 更 快 。 


二 又 查找 树 可 以 任意 地 构造 ， 同 样 是 2、3、5、6、7、8 这 五 个 数 
字 ， 也 可 以 按照 图 5-3 的 方式 建立 二 又 查找 树 。 

图 5-3 的 平均 查找 次 数 为 〈1+2+3+4+5+5) /6=3.16 次 ， 和 顺序 查找 
差不多 。 显 然 这 棵 二 又 查找 树 的 查询 效率 就 低 了 。 因 此 知 想 最 大 性 能 地 
构造 一 棵 二 又 查找 树 ， 需 要 这 棵 二 又 查找 树 是 平衡 的 ， 从 而 引出 了 新 的 
定义 一 一 平衡 二 又 树 ， 或 称 为 AVL 树 。 


\ 


5 


N; 
/ N 


图 5-3 BER BURA PROCEED 
平衡 二 又 树 的 定义 如 下 : BAFA ETN EM HRU 











足 任何 节点 的 两 个 子 树 的 高 度 最 大 差 为 1。 显 然 ， 图 5-3 不 满足 平衡 二 
树 的 定义 ， 而 图 5-2 是 一 棵 平衡 二 广 树 。 平 衡 二 叉 树 的 查找 性 和 ud 
高 的 ， 但 不 是 最 高 的 ， 只 是 接近 最 高 性 能 。 最 好 的 性 能 需要 建立 一 棵 最 
优 二 叉 树 ， 但 是 最 优 二 又 树 的 建立 和 维护 需要 大 量 的 操作 ， 因 此 ， 用 户 
一 般 只 需 建 立 一 棵 平衡 二 叉 树 即 可 。 


平衡 三 SUBSET CORE HORA [E Xe FE — ER T fg A ARAT 
是 非常 大 的 。 通 第 来 说 ， 需 要 1 次 或 多 次 左旋 和 右 旋 来 得 到 插入 或 更 新 
后 树 的 平衡 性 。 对 于 图 5-2 所 示 的 平衡 树 ， 当 用 户 需 要 插入 一 个 新 的 键 
值 为 9 的 节点 时 ， 需 做 如 图 5-4 所 示 的 变动 。 











插入 新 值 9 
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左旋 以 保证 平衡 


图 5-4 插入 键 什 9， 平衡 二 又 树 的 变化 


这 里 通过 一 次 左旋 操作 就 将 插入 后 的 树 重新 变 为 平衡 的 了 。 但 是 有 
的 情况 可 能 需要 多 次 ， 如 图 5-5 所 示 。 
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再 左旋 一 次 


图 5-5 需 多 次 旋转 的 平衡 二 又 树 


图 5-4 和 图 5-5 中 列举 了 回 一 棵 平衡 二 叉 树 插入 一 个 新 的 节点 后 ， 平 
衡 二 叉 树 需要 做 的 旋转 操作 。 除 了 插入 操作 ， 还 有 更 新 和 删除 操作 ， 不 
过 这 和 插入 没有 本 质 的 区 别 ， 都 是 通过 左旋 或 者 右 旋 来 完成 的 。 因 此 对 
一 棵 平衡 树 的 维护 是 有 一 定 开销 的 ， 不 过 平衡 二 又 树 多 用 于 内 存 结构 对 
象 中 ， 因 此 维护 的 开销 相对 较 小 。 








5.3 ”B+ 树 


B+ 树 和 二 叉 树 、 平 衡 二 叉 树 一 样 ， 都 是 经 典 的 数据 结构 。B+ 树 由 B 
树 和 索引 顺序 访问 方法 (ISAM， 是 不 是 很 熟悉 ? 对 ， 这 也 是 MyISAM 
引擎 最 初 参考 的 数据 结构 〉 演 化 而 来 ， 但 是 在 现实 使 用 过 程 中 几乎 已 经 
没有 使 用 B 树 的 情况 了 。 


B+ 树 的 定义 在 任何 一 本 数据 结构 书 中 都 能 找到 ， 其 定义 十 分 复 
杂 ， 在 这 里 列 出 来 只 会 让 读者 感到 更 加 困惑 。 这 里 ， 我 来 精简 地 对 
B+ 树 做 个 介绍 : B+ 树 是 为 磁盘 或 其 他 直接 存 取 辅 助 设备 设计 的 一 种 平 
衡 查 找 树 。 在 B+ 树 中 ， 所 有 记录 节点 都 是 按键 值 的 大 小 顺序 存放 在 同 
一 层 的 叶子 节点 上 ， 由 各 叶子 节点 指针 进行 连接 。 先 来 看 一 个 B+ 树 ， 
其 高 度 为 2， 每 页 可 存放 4 条 记录 ， 局 出 〈fan out) 为 5， 如 图 5-6 所 示 。 
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图 5-6 一 棵 高 度 为 2 的 B+ 树 





从 图 5-6 可 以 看 出 ， 所 有 记录 都 在 叶子 节点 上 ， 并 且 是 顺序 存放 
的 ， 如 果 用 户 从 最 左边 的 叶子 节点 开始 顺序 过 历 ， 可 以 得 到 所 有 键 值 的 
顺序 排序 : 5、10、15、20、25、30、50、55、60、65、75、80、85、 
90。 


5.3.1 B+ 树 的 插入 操作 


B+ 树 的 插入 必须 保证 插入 后 叶子 节点 中 的 记录 依然 排序 ， 同 时 需 
要 考虑 插入 到 B+ 树 的 三 种 情况 ， 每 种 情况 都 可 能 会 导致 不 同 的 插入 算 
法 。 如 表 5-1 所 示 。 


LeafPagei | Index Page $ Li: 
No No CRAB TR 


| 
JN 
pu — 
ATAT PANA 








D d Leaf Page 

2) APA AA 

3 AFATAN 
Ye Ye 4) f Index Pag 

j 

| 

| 


= 


PPAT ANNE 
KERR ENC RICE 
WATANA L-E Idex Pg 








这 里 用 一 个 例子 来 分 析 B+ 树 的 插入 。 例 如 ， 对 于 图 5-6 中 的 这 标 
B+ 树 ， 知 用 户 插入 28 这 个 键 值 ， 发 现 当 前 Leaf Page 和 Index Page 都 没有 
满 ， 直 接 进行 插入 即 可 ， 之 后 得 图 5-7。 
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图 5-7 插入 键 值 28 


接着 再 插入 70 这 个 键 值 ， 这 时 原先 的 Leaf 。 ”Page 己 经 满 了 ， 但 是 
Index Page 还 没有 满 ， 符 合 表 5-1 的 第 二 种 情况 ， 这 时 插入 Leaf Page 后 的 
情况 为 55、55、60、65、70， 并 根据 中 间 的 值 60 来 拆 分 叶子 节点 ， 可 得 
图 5-8。 
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5-8 插入 键 值 70 


因为 图 片 显示 的 关系 ， XARRA R BERIT en EXN ER E 
针 。 不 过 和 图 5-6、 图 5-7 一 样 ， 它 还 是 存在 的 。 


最 后 插入 键 值 95， 这 时 符合 表 5-1 中 讨 t CRI — 种 情况 ， 即 Leaf 
Page 和 Index Page 都 满 了 ， 这 时 需要 做 两 次 拆 分 ， 如 图 5-9 所 示 。 
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图 5-9 插入 键 值 95 


可 以 看 到 ， 不 管 怎么 变化 ，B+ 树 总 是 会 保持 平衡 。 但 是 为 了 保持 
平衡 对 于 新 插入 的 键 值 可 能 需要 做 大 量 的 拆 分 页 〈split) 操作 。 因 为 
B+ 树 结构 主要 用 于 磁盘 ， 页 的 拆 分 意味 着 磁盘 的 操作 ， 所 以 应 该 在 可 
能 的 情况 下 尽量 减少 页 的 拆 分 操作 。 因 此 ，B+ 树 同样 提供 了 类 似 于 平 





衡 二 又 树 的 旋转 (Rotation〉 功能 。 


旋转 发 生 在 Leaf Page 已 经 满 ， 但 是 其 的 左右 兄弟 节点 没有 满 的 情况 
下 。 这 时 B+ 树 并 不 会 急于 去 做 拆 分 页 的 操作 ， 而 是 将 记录 移 到 所 在 页 
的 兄弟 亨 把 上 。 在 通常 情况 下 ， 左 兄 第 会 被 首先 检查 用 来 做 旋转 操作 ， 
因此 再 来 看 图 5-7 的 情况 ， 知 插入 键 值 70， 其 实 B+ 树 并 不 会 急于 去 拆 分 
叶子 市 点 ， 而 是 去 做 旋转 操作 ， 得 到 如 图 5-10 所 示 的 操作 。 


Ha. 
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图 530 ”B+ 树 的 旋转 操作 


从 图 5-10 可 以 看 到 ， 采 用 旋转 操作 使 B+ 树 减 少 了 一 次 页 的 拆 分 操 
作 ， 同 时 这 棱 B+ 树 的 高 度 依然 还 是 2。 


5.8.3. B+ 树 的 删除 操作 

B+ 树 使 用 填充 因子 fill factor) 来 控制 树 的 删除 变化 ，50% 是 填充 
因子 可 设 的 最 小 值 。B+ 树 的 删除 操作 同样 必须 保证 删除 后 叶子 节点 中 
的 记录 依然 排序 ， 同 插入 一 样 ，B+ 树 的 删除 操作 同样 需要 考虑 以 下 表 5- 
2 中 的 三 种 情况 ， 与 插入 不 同 的 是 ， 删 除根 据 填充 因子 的 变化 来 衡量 。 
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根据 图 5-9 的 B+ 树 来 进行 删除 操作 。 首 先 删除 键 值 为 70 的 这 条 记 
录 ， 该 记录 符合 表 5-2 讨 论 的 第 一 种 情况 ， 删 除 后 可 得 到 图 5-11。 
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图 5-11 删除 键 值 70 
接着 删除 键 值 为 25 的 记录 ， 这 也 是 表 5-2 讨 论 的 第 一 种 情况 ， 但 是 





该 值 还 是 mdexPage 中 的 值 ， 因 此 在 删除 Leaf Page 中 的 25 后 ， 还 应 将 25 
的 右 兄弟 节点 的 28 更 新 到 Page Index 中 ， 最 后 可 得 图 5-12。 
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图 5-312 删除 键 值 25 


最 后 看 删除 键 值 为 60 的 情况 。 删 除 Leaf Page 中 键 值 为 60 的 记录 后 ， 
Fill Factor 小 于 50%， 这 时 需要 做 合并 操作 ， 同 样 ， 在 删除 mdex Page 中 
相关 记录 后 需要 做 Index Page 的 合并 操作 ， 最 后 得 到 图 5-13。 
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5-13 删除 键 值 60 


5.4 B+ 树 索引 


前 面 讨论 的 都 是 B+ 树 的 数据 结构 及 其 一 般 操 作 ，B+ 树 索引 的 本 质 
就 是 B+ 树 在 数据 库 中 的 实现 。 但 是 B+ 索 引 在 数据 库 中 有 一 个 特点 是 高 
矶 出 性 ， 因 此 在 数据 库 中 ，B+ 树 的 高 度 一 般 都 在 2 一 4 层 ， 这 也 就 是 说 
查找 某 一 键 值 的 行 记 录 时 最 多 只 需要 2 到 4 次 IO， 这 倒 不错 。 因 为 当前 一 
LI LASER REED ED 可 以 做 100 次 ID，2 一 4 次 的 IO 意味 着 查询 时 间 只 
需 0.02 一 0.04 秒 。 


数据 库 中 的 B+ 树 索引 可 以 分 为 聚集 索引 Clustered inex) 和 辅助 索 
5| Csecondary index) 呈 ， 但 是 不 管 是 聚集 还 是 辅助 的 索引 ， 其 内 部 都 是 
B+ 树 的 ， 即 高 度 平 衡 的 ， 叶 子 节点 存放 着 所 有 的 数据 。 聚 集 索 引 与 畏 
助 索 引 不 同 的 是 ， 叶 子 节点 存放 的 是 否 是 一 整 行 的 信息 。 


5.4.1 聚集 索引 


之 前 已 经 介绍 过 了 ，InnoDB 存 储 引 擎 表 是 索引 组 织 表 ， 即 表 中 数 
据 按照 主键 顺序 存放 。 而 聚集 索引 Cclustered index) 就 是 按照 每 张 表 的 
主键 构造 一 棵 B+ 树 ， 同 时 叶子 节点 中 存放 的 即 为 整 张 表 的 行 记录 数 
据 ， 也 将 聚集 索引 的 叶子 节点 称 为 数据 页 。 聚 集 索 引 的 这 个 特性 决定 了 
索引 组 织 表 中 数据 也 是 索引 的 一 部 分 。 同 B+ 树 数据 结构 一 样 ， 每 个 数 
据 页 都 通过 一 个 双 辐 链表 来 进行 链接 。 


由 于 实际 的 数据 页 只 能 按照 一 棵 B+ 树 进行 排序 ， 因 此 每 张 表 只 能 
拥有 一 个 聚集 察 引 。 在 多 数 情况 下 ， 碍 询 优 化 需 倾 加 于 采用 聚集 察 引 。 
因为 聚集 索引 能 够 在 B+ 树 索引 的 叶子 节点 上 直接 找到 数据 。 此 外 ， 由 
于 定义 了 数据 的 迎 辑 顺序 ， 聚 集 索 引 能 够 特别 快 地 访问 针对 范围 值 的 伍 
询 。 碍 询 优化 器 能 够 快速 发 现 芭 一 段 范围 的 数据 页 需要 扫描 。 


接着 来 看 一 张 表 ， 这 里 以 人 为 的 方式 让 其 每 个 页 只 能 存放 两 个 行 记 
如 : 









































CREATE TABLE t ( 
a IN > 
b VARCHAR(8000), 
NT NOT NULL, 
PRIMARY KEY(a), 
idx c(c 
) ENGINE=INNODB; 
INSERT INTO t SELECT 1,REPEAT('a', 7000), -1; 


INSERT INTO t SELECT 2,REPEAT('a', 7000), -2; 
INSERT INTO t SELECT 3,REPEAT('a', 7000), -3; 


INSERT INTO t SELECT 4,REPEAT('a', 7000), -4; 





在 上 述 例子 中 ， 插 入 的 列 b 长 度 为 7000， 因 此 可 以 以 人 为 的 方式 使 
目前 每 个 页 只 能 存放 两 个 行 记 录 。 接 着 用 py_innodb_page_info 工 具 来 分 
析 表 空间 ， 可 得 : 














[rootQünineyouO-43 data]#py_innodb_page_info.py-v mytest/t.ibd 
page offset 00000000, page type<File Space Header> 

page offset 00000001,page type<Insert Buffer Bitmap> 

page offset 00000002,page type<File Segment inode> 

page offset 00000003,page type<B-tree Node>,page level<0001> 
page offset 00000004, page type<B-tree Node>,page level<o000> 
page offset 00000005,page type<B-tree Node>,page level<o000> 
page offset 00000006,page type<B-tree Node>,page level<0000> 
page offset 00000000,page type<Freshly Allocated Page> 

Total number of page:8: 

Freshly Allocated Page:1 

Insert Buffer Bitmap:1 

File Space Header:1 

B-tree Node:4 

File Segment inode:1 








page level 为 0000 的 即 是 数据 页 ， 而 前 面 的 章节 也 对 数据 页 进行 了 分 
析 ， 所 以 这 不 是 当前 所 需要 关注 的 部 分 。 要 分 析 的 是 page level 为 0001 的 
页 ， 当 前 聚集 索引 的 B+ 树 高 度 为 2， 故 该 页 是 B+ 树 的 根 。 通 过 hexdump 
工具 来 观察 索引 的 根 页 中 所 存放 的 数据 ; 

















06000c000 c2 33 62 95 00 00 00 03 ff ff ff ff ff ff ff ff|.3b............. 
0000c010 00 00 00 Oa b6 8c ce 57 45 bf 00 00 00 00 00 00|....... WE 
0000c020 00 00 00 00 00 f9 00 02 00 a2 80 05 00 OO OO 00|................ 
0000c030 00 9a 00 02 OO 02 OO 03 00 00 00 OO 00 OO 00 00|................ 
0000c040 00 01 00 00 00 OO 00 00 O1 e2 00 00 00 f9 OO 00|................ 
0000c050 00 02 00 f2 00 00 00 f9 00 00 OO 02 OO 32 01 00|............. 255 
0000c060 02 00 1b 69 Ge 66 69 6d 75 6d 00 04 00 Ob 00 00|...infimum...... 
0000c070 73 75 70 72 65 6d 75 6d 00 10 00 11 00 Qe 80 00|supremum........ 
0000c080 00 O1 00 OO OO 04 OO OO OO 19 00 Oe 80 OO OO 02]|................ 
0000c090 00 00 00 05 00 00 00 21 ff d6 80 00 00 04 00 00|.......!........ 
0000cOa0 00 06 00 OO OO OO OO OO OO OO 00 OO 00 OO OO 00|................ 
0000cObO O00 00 00 00 00 OO OO 00 OO 00 00 00 OO OO OO 00|................ 
0000cOcO 00 OO 00 OO OO OO OO OO OO OO 00 OO 00 OO OO 00|................ 








0000fffO O0 00 00 00 OO 70 00 63 73 d8 52 3a b6 8c ce 57]|.....p.cs.R:...W 





这 里 可 以 直接 通过 页 尾 的 Page Directory 来 分 析 此 页 。 从 00 63 可 以 
知道 该 页 中 行 开 始 的 位 置 ， 接 着 通过 Recorder Header 来 分 析 ，0xc063 开 
始 的 值 为 69 6e 66 69 6d 75 6d 00， 就 代表 infimum 为 行 记 录 ， 之 前 的 5 字 
节 01 00 02 00 1b 就 是 Recorder Header， 分 析 第 4 位 到 第 8 位 的 值 1 代 表 该 
行 记录 中 只 有 一 个 记录 (需要 记 住 的 是 ，InnoDB 的 Page  Directoryzé f 
BAY) ， 即 infimum 记 录 本 身 。 通 过 Recorder Header 中 最 后 的 两 个 字 节 
00 1b 来 判断 下 一 条 记录 的 位 置 ， 即 c063+1b=c07e， 读 取 键 值 可 得 80 00 
00 01， 这 就 是 主键 为 1 的 键 值 〈 表 定义 时 INT 是 无 符号 的 ， 因 此 二 进 制 
是 0x80 00 00 01， 而 不 是 0x0001) , 80 00 00 01 后 的 值 00 00 00 04 代 表 
指 回 数据 页 的 页 号 。 同 样 的 方式 可 以 找到 80 00 00 02 和 80 00 00 04 这 两 
个 键 值 以 及 它们 指向 的 数据 页 。 

















通过 以 上 对 非 数 据 页 节点 的 分 机 ， 可 以 及 现 数据 页 上 存放 的 是 完整 
的 每 行 的 记录 ， 而 在 非 数据 页 的 索引 页 中 ， 存 放 的 仅仅 是 键 值 及 指 同 数 
据 页 的 仿 移 量 ， 而 不 是 一 个 完整 的 行 记录 。 因 此 这 标 聚 集 索 引 树 的 构造 
大 致 如 图 5-14 所 示 。 

















Page Offset: 0003 GERA) 


Key: 80000001 |} Key: 80000002 | | Key: 80000004 
Pointer 0004 Pointer, 0005 Pointer: 0000 








Page Offset: 00 04 Page Offset. 0005 Page Offset: 0006 






Lrepeat (a 1000) Drepeat (a ,7000) | | | | repeat (a ,7000) 
repeat (4 ,7000) 





图 5-34 B+ 树 索引 


许多 数据 库 的 文档 会 这 样 告诉 读者 : 聚集 索引 按照 顺序 物理 地 存储 
数据 。 如 果 看 图 5-14， 可 能 也 会 有 这 样 的 感觉 。 但 是 试想 一 下 ， 如 果 聚 











集 索 引 必 须 按照 特定 顺序 存放 物理 记录 ， 则 维护 成 本 显得 非常 之 高 。 所 
以 ， 聚 集 索引 的 存储 并 不 是 物理 上 连续 的 ， 而 是 逻辑 上 连续 的 。 这 其 中 
有 两 点 : 一 是 前 面 说 过 的 页 通过 双 回 链表 链接 ， 页 按照 主键 的 顺序 排 
序 ; 为 一 点 是 每 个 页 中 的 记录 也 是 通 过 双向 链 失 进行 维护 的 ， 物理 存储 
上 可 以 同样 不 按照 主键 存储 。 


聚集 索引 的 另 一 个 好 处 是 ， 它 对 于 主键 的 排序 查找 和 范围 查找 速度 
非常 快 。 叶 子 节 点 的 数据 就 是 用 户 所 要 查询 的 数据 。 如 用 户 需 要 查询 一 
张 注册 用 户 的 表 ， 查 询 最 后 注册 的 10 位 用 户 ， 由 于 B+ 树 索 引 是 双向 链 
表 的 ， 用 户 可 以 快速 找到 最 后 一 个 数据 页 ， 并 取出 10 条 记录 。 奉 用 命令 
EXPLAIN 进 行 分 析 ， 可 得 : 





























mysql EXPLAIN 
->SELECT*FROM Profile ORDER BY id LIMIT 1056; 


XO RO ORO ROO ROG RO ROO ROG EO Ge] py ek e e TOR eR e Re e Re 


id: 
ect Pm eee 
tal ae 
Pee 
ible ke eys:NULL 
ke ey: PRIMARY 

:4 


ra: 
1 row in set(0.00 sec) 











可 以 看 到 虽然 使 用 ORDER BY 对 记录 进行 排序 ， 但 是 在 实际 过 程 中 
并 没有 进行 所 谓 的 filesort 操 作 ， 而 这 就 是 因为 聚集 索引 的 特点 。 


另 一 个 是 范围 查询 (range query) ， 即 如 果 要 查找 主键 某 一 范围 内 
的 数据 ， 通 过 叶子 节点 的 上 层 中 间 节 点 就 可 以 得 到 页 的 范围 ， 之 后 直接 
读 取 数据 页 即 可 ， 又 如 : 

















mysql>EXPLAIN 
->SELECT*FROM Profile 
->WHERE id>10 AND Hae 109006) 


FOI IGG ICICI ICI ICICI py eR Ro e ICR RKKK RKKK KKK KK 


id:1 

S ct bd S GERE 
able 

type Ange 

ible _ keys : PRIMARY 

kg ae SPRIMARY 

key len:4 


g where 
1 row in set (0.01 sec) 





执行 EXPLAIN 得 到 了 MySQL 数 据 库 的 执行 计划 (execute plan) , 
并 且 在 rows 列 中 给 出 了 一 个 查询 结 果 的 预 估 返 回 行 数 。 要 注意 的 是 ， 
rows 代 表 的 是 一 个 预 估 值 ， 不 是 确切 的 值 ， 如 有 条 实际 执行 这 名 SQL 的 得 


询 ， 可 以 看 到 实际 上 只 有 9946 行 记录 : 





mysql>SELECT COUNT(* yoram S 
->WHERE id>10 AND id<1 
FOI ICI III IIIT III 
COUNT (1) :9946 
1 row in set(0.00 sec) 





OMDR AN th RSE SESE RG] Cnon-clustered index) . 


5.4.2 ”辅助 索引 


对 于 辅助 索引 (Secondary Index， 也 称 非 聚集 索引 ) ， 叶 子 节 点 并 
不 包含 行 记录 的 全 部 数据 。 叶 子 节 点 除了 包含 键 值 以 外 ， 每 个 叶子 节点 
中 的 索引 行 中 还 包含 了 一 个 书签 (bookmark) 。 该 书签 用 来 告诉 
InnoDB 存 储 引 擎 哪里 可 以 找到 与 索引 相对 应 的 行 数据 。 由 于 InnoDB 存 
储 引 擎 表 是 索引 组 织 表 ， 因 此 InnoDB 存 储 引 擎 的 辅助 索引 的 书签 就 是 
相应 行 数据 的 聚集 索引 键 。 图 5-15 显 示 了 InnoDB 存 储 引擎 中 辅助 索引 与 
聚集 索引 的 关系 。 


















Secondary Index Secondary Index 





Clustered Index 
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辅助 索引 的 存在 并 不 影响 数据 在 聚集 索引 中 的 组 织 ， 因 此 每 张 表 上 
可 以 有 多 个 辅助 索引 。 当 通过 辅助 索引 来 寻找 数据 时 ，InnoDB 存 储 引 
擎 会 般 历 辅助 索引 并 通过 叶 级 别 的 指针 获得 指 加 主键 索引 的 主键 ， 然 后 
再 通过 主键 索引 来 找到 一 个 完整 的 行 记 录 。 举 例 来 说 ， 如 果 在 一 株 高 度 
为 3 的 辅助 索引 树 中 碍 找 数 据 ， 那 需要 对 这 株 辅 助 索 引 树 通 历 3 次 找到 指 
定 主 键 ， 如 果 聚 集 索 引 树 的 高 度 同 样 为 3， 那 么 还 需要 对 聚集 索引 树 进 
行 3 次 得 找 ， 最 终 找 到 一 个 完整 的 行 数据 所 在 的 页 ， 因 此 一 共 需 要 6 次 多 
辑 IO 访问 以 得 到 最 终 的 一 个 数据 页 。 


对 于 其 他 的 一 些 数据 库 ， 如 Microsoft SQL Server 数 据 库 ， 其 有 一 种 
称 为 堆 表 的 表 类 型 ， 即 行 数据 的 存储 按照 插入 的 顺序 存放 。 这 与 
MySQL 数 据 库 的 MyISAM 存 储 引 擎 有 些 类 似 。 堆 表 的 特性 雇 定 了 堆 表 上 
的 索引 都 是 非 聚 集 的 ， 主 键 与 非 主 键 的 区 别 只 是 是 否 唯一 且 非 空 (NOT 
NULL) 。 因 此 这 时 书签 是 一 个 行 标识 符 (Row Identifiedr, RID) ， 可 
以 用 如 “文件 号 : 页 号 : 槽 号 ”的 格式 来 定位 实际 的 行 数据 。 


有 的 Microsoft SQL Server 数 据 库 DBA 问 过 我 这 样 的 问题 ， 为 什么 在 
Microsoft SQL Server 数 据 库 上 还 要 使 用 索引 组 织 表 ? 堆 表 的 书签 使 非 聚 
集 碍 找 可 以 比 主键 书签 方式 更 快 ， 并 且 非 聚集 可 能 在 一 张 表 中 存在 多 
个 ， 我 们 需要 对 多 个 非 肾 集 索 引进 行 查 找 。 而 且 对 于 非 聚 集 索 引 的 离散 
读 取 ， 有 索引 组 织 表 上 的 非 聚 集 索 引 会 比 堆 表 上 的 聚集 索引 慢 一 些 。 


当然 ， 在 一 些 情况 下 ， 使 用 堆 表 的 确 会 比索 引 组 织 表 更 快 ， 但 是 我 
觉得 大 部 分 原因 是 由 于 存在 OLAP (On-Line Analytical Processing， 在 线 
分 析 处 理 ) 的 应 用 。 其 次 就 是 前 面 提 到 的 ， 表 中 数据 是 否 需 要 更 新 ， 并 
且 更 新 是 人 否 影 响 到 物理 地 址 的 变更 。 此 外 另 一 个 不 能 忽视 的 是 对 于 排序 
和 范围 查找 ， 索 引 组 织 表 通过 B+ 树 的 中 间 市 点 就 可 以 找到 要 查找 的 所 
有 页 ， 然 后 进行 读 取 ， 而 堆 表 的 特性 决定 了 这 对 其 是 不 能 实现 的 。 最 
后 ， 非 聚集 索引 的 离散 读 ， 的 确 存 在 上 述 的 情况 ， 但 是 一 般 的 数据 库 都 
通过 实现 预 谈 (read ahead) 技术 来 避 倪 多 次 的 离散 读 操 作 。 因 此 ， 具 
体 是 建 堆 表 还 是 索引 组 织 表 ， 这 取决 于 应 用 ， 不 存在 哪个 更 优 的 问题 。 
这 和 InnoDB 存 储 引擎 好 还 是 MyISAM 存 储 引擎 好 这 个 问题 的 答案 是 一 样 
HJ, Itall depends. 


接着 通过 阅读 表 衬 间 文 件 来 分 机 InnoDB 存 储 引 警 的 非 聚集 索引 的 
实际 存储 。 还 是 分 析 上 一 小 节 所 用 的 表 t。 不 同 的 是 ， 在 表 t 上 再 建立 一 






























































个 列 c， 并 对 列 c 创 建 非 聚 集 索引 : 





mysql>ALTER TABLE t 

->ADD c INT NOT NULL; 

Query OK,4 rows affected(0.24 sec) 
Records:4 Duplicates:0 Warnings:0 
mysql>UPDATE t SET c-0-a; 

Query OK,4 rows affected(0.04 sec) 
Rows matched:4 Changed:4 Warnings:0 
mysql>ALTER TALBE t ADDKEY idx_c(c); 
Query OK,4 rows affected(0.28 sec) 
Records:4 Duplicates:0 Warnings:0 
mysql>SHOW INDEX FROM t\G; 
JOOOOOOOOOOOOOOOOIOOOIOOOOORR LI pj FIG III ICICI III III III Ie 
Table:t 

Non_unique:0 

Key_name: PRIMARY 

Seq_in_index:1 

Column_name:a 

Collation:A 

Cardinality:2 

Sub_part:NULL 

Packed: NULL 

Null: 

Index type:BTREE 

Comment : 
JOOOOOOOOOOOROOOOOOOOOOOOOERK D | pj FSC ICICI III III III Ie 
Table:t 

Non_unique:1 

Key name:idx c 

Seq in index:1 

Column name:c 

Collation:A 

Cardinality:2 

Sub part:NULL 

Packed:NULL 

Null: 

Index type:BTREE 

Comment : 

2 rows in set (0.00 sec) 
mysql>select a,c from t; 
+---+----+ 

laici 

+---+----+ 

141-41 

131-3| 

121-21| 

111-1] 

+---+----+ 

4 rows in set (0.00 sec) 








然后 用 py_innodb_page_info 工 具 来 分 析 表 空间 ， 可 得 : 





[root@nineyou0-43 mytest]#py_innodb_page_info.py-v t.ibd 

page offset 00000000,page type<File Space Header> 

page offset 00000001,page type<Insert Buffer Bitmap> 

page offset 00000002,page type<File Segment inode> 

page offset 00000003, page type<B-tree Node>,page level<0001> 
page offset 00000004, page type<B-tree Node>,page level-c0000-— 
page offset 00000005,page type<B-tree Node>,page level-c0000-— 
page offset 00000006,page type<B-tree Node>,page level-c0000-— 
page offset 00000007,page type<B-tree Node>,page level-c0000-— 
page offset 00000000,page type<Freshly Allocated Page> 

Total number of page:9: 

Freshly Allocated Page:1 

Insert Buffer Bitmap:1 

File Space Header:1 

B-tree Node:5 

File Segment inode:1 





对 比 前 一 次 分 析 ， 我 们 可 以 看 到 这 次 多 了 一 个 页 。 分 析 page offset 
为 4 的 页 ， 该 页 即 为 非 聚集 索引 所 在 页 ， 通 过 工具 hexdump 分 析 可 得 : 





00010000 b9 aa 8e dO 00 00 00 04 ff ff ff ff ff ff ff ff|...............， 
00010010 00 00 00 Oa ec ea 4e 27 45 bf 00 00 00 00 00 00|...... N*E. ài 


00010020 
00010030 
00010040 
00010050 
00010060 
00010070 
00010080 
00010090 
000100a0 











06613ffg 





由 于 只 有 4 行 数据 ， 并 且 列 c 只 有 4 字 节 ， 因 此 在 一 个 非 聚集 索引 页 
中 即 可 完成 ， 整 理 分 析 可 得 如 图 5-16 所 示 的 关系 。 








铺 助 索引 dx c 


Page Offset:00 04 
Key:7f ff ff ff Key:7f ff ff fe Key: 7f ff ff fd Key: 7f fff fe 
Pointer:80 00.0001 |} Pointer:80 000002 || Pointer:80 00.00.03 |} Pointer:80 00 00 04 
| 
















聚集 索引 Page Offset:00 03 


Key:80 00 0001 Key:80 00 00 02 Key:80 00 00 04 
Pointer:00 05 Pointer:00 06 Pointer:00 07 


Page Offset:00 05 Page Offset:00 06 Page Offset:00 07 


[repeat (^a ,7000) , 2 repeat 2,7000) .-2 | | | repeat (3 .7000) -4 
-| 3 repeat (4,7000) ,-3 





Al 5-16 Ez SI PT 


图 5-16 显 示 了 表 t 中 辅助 索引 idx_c 和 聚集 索引 的 关系 。 可 以 看 到 辅 
助 索 引 的 叶子 节点 中 包含 了 列 c 的 值 和 主键 的 值 。 因 为 这 里 我 特意 将 键 
值 设 为 负 值 ， 所 以 会 发 现 -1 以 7f ff ff ff 的 方式 进行 内 部 存储 。7 (0111) 
最 高 位 为 0， 代 表 负 值 ， 实 际 的 值 应 该 取 反 后 加 1， 即 得 -1。 


543 B+ 树 索 引 的 分 列 


在 5.3 节 中 介绍 B+ 树 的 分 裂 是 最 为 简单 的 一 种 情况 ， 这 和 数据 库 中 
B+ 树 索 引 的 情况 可 能 略 有 不 同 。 此 外 5.3 市 页 没有 涉及 并 及 ， 而 这 才 是 
B+ 树 索 引 实 现 最 为 困难 的 部 分 。 


B+ 树 索引 页 的 分 裂 并 不 总 是 从 页 的 中 间 记 录 开 始 ， 这 样 可 能 会 导 
致 页 空间 的 浪费 。 例 如 下 面 的 记录 : 








1.2.3.4. 5, 6. 7. 8. 9 














插入 是 根据 自 增 顺 序 进行 的 ， 若 这 时 插入 10 这 条 记录 后 需要 进行 页 
的 分 裂 操 作 ， 那 么 根据 5.3.1 节 介绍 的 分 裂 方法 ， 会 将 记录 5 作为 分 裂 点 
记录 (split record) ， 分 裂 后 得 到 下 面 两 个 页 : 








P1: 1. 2. 3. 4 
P2: 5. 6. 7. 8. 9. 10 











然而 由 于 插入 是 顺序 的 ，P1 这 个 页 中 将 不 会 再 有 记录 被 插入 ， 从 而 
导致 空间 的 浪费 。 而 P2 又 会 再 次 进行 分 裂 。 


InnoDB 存 储 引 擎 的 Page Header 中 有 以 下 几 个 部 分 用 来 保存 插入 的 
顺序 信息 : 


LIPAGE LAST INSERT 





LIPAGE DIRECTION 


LIPAGE N DIRECTION 





通过 这 些 信 息 ，InnoDB 存 储 引 擎 可 以 决定 是 同 左 还 是 回 右 进行 分 
裂 ， 同 时 决定 将 分 裂 点 记录 为 哪 一 个 。 知 插入 是 随机 的 ， 则 取 页 的 中 间 
记录 作为 分 裂 点 的 记录 ， 这 和 之 前 介绍 的 相同 。 知 往 同 一 方 癌 进行 插入 
的 记录 数量 为 5， 并 且 目 前 已 经 定位 (cursor) 到 的 记录 (InnoDB 存 储 
引擎 插入 时 ， 首 先 需要 进行 定位 ， 定 位 到 的 记录 为 竺 插入 记录 的 前 一 条 
WR) 之 后 还 有 3 条 记录 ， 则 分 裂 点 的 记录 为 定位 到 的 记录 后 的 第 三 条 
记录 ， 否 则 分 裂 点 记录 就 是 待 插入 的 记录 。 











来 看 一 个 向 右 分 裂 的 例子 ， 并 且 定 位 到 的 记录 之 后 还 有 3 条 记录 ， 
则 分 裂 点 记录 如 图 5-17 所 示 。 


Page 


cursor record split record 


md 


record to be insert 
图 5-17 辐 右 分 裂 的 一 种 情况 








图 5-17 回 右 分 裂 且 定位 到 的 记录 之 后 还 有 3 条 记录 ，split record 为 分 
裂 点 记录 最 终 同 右 分 裂 得 到 如 图 5-18 所 示 的 情况 。 





Page Right Page 


cursor record split record 





HHHH 


record to be insert 
图 5-18 回 右 分 裂 后 页 中 记录 的 情况 





对 于 图 5-19 的 情况 ,分裂 点 就 为 插入 记录 本 里， 向 右 分 裂 后 仅 插 入 
记录 本 身 ， 这 在 自 增 插入 时 是 普遍 存在 的 一 种 情况 。 


cursor record 


Mth 


record to be insert 








After Split 


Right Page 


cursor record 


split record 


record to be insert 


图 5-19 回 右 分 裂 的 另 一 种 情况 


5.4.4 B+ 树 索 引 的 管理 
1. 索 引 管 理 
索引 的 创建 和 删除 可 以 通过 两 种 方法 ， 一 种 是 ALTER TABLE, 5j 


一 种 是 CREATE/DROP INDEX。 通 过 ALTER _ TABLE 创建 索引 的 语法 
H: 





ALTER TABLE tbl_name 

|ADD(INDEX|KEY) [index name] 

[index type](index col name,...)[index option]... 
ALTER TABLE tbl name 

DROP PRIMARY KEY 

| DROP{INDEX | KEY}index_name 





CREATE/DROP INDEX 的 语法 同样 很 简单 : 





CREATE[UNIQUE]INDEX index_name 
[index type] 

ON tbl name(index col name,...) 
DROP INDEX index name ON tbl. name 





用 户 可 以 设置 对 整个 列 的 数据 进行 索引 ， 也 可 以 只 索引 一 个 列 的 开 
头 部 分 数据 ， 如 前 面 创建 的 表 t， 列 b 为 varchar (8000) ， 但 是 用 户 可 以 
只 索引 前 100 个 字段 ， 如 : 





mysql>ALTER TABLE t 

-—ADD KEY idx b(b(100)); 

Query OK,4 rows affected(0.32 sec) 
Records:4 Duplicates:0 Warnings:0 











若 用 户 想 要 查看 表 中 索引 的 信息 ， 可 以 使 用 命令 SHOW INDEX. 
下 面 的 例子 使 用 之 前 的 表 t， 并 加 一 个 对 于 列 (a，c) 的 联合 索引 
idx_a_c， 可 得 : 





mysql>ALTER TABLE t 

->ADD KEY idx a c(a,c); 

Query OK,4 rows affected(0.31 sec) 
Records:4 Duplicates:0 Warnings:O 
mysql- SHOW INDEX FROM t\G; 


Table:t 

Non unique:9 

Key name:PRIMARY 
Seq in index:1 
Column name:a 
Collation:A 
Cardinality:2 
Sub part:NULL 
Packed:NULL 
Null: 

Index type:BTREE 


Comment : 


Table:t 

Non unique:1 
Key name:idx b 
Seq in index:1 
Column name:b 
Collation:A 
Cardinality:2 
Sub part:100 
Packed:NULL 
Null:YES 

Index type:BTREE 
Comment : 


Table:t 

Non unique:1 

Key name:idx a c 
Seq in index:1 
Column name:a 
Collation:A 
Cardinality:2 
Sub part:NULL 
Packed:NULL 
Null: 

Index type:BTREE 
Comment : 


Table:t 

Non unique:1i 

Key name:idx a c 
Seq in index:2 
Column name:c 
Collation:A 
Cardinality:2 
Sub part:NULL 
Packed:NULL 
Null: 

Index type:BTREE 
Comment : 


Table:t 

Non unique:1 

Key name:idx c 
Seq in index:1 
Column name:c 
Collation:A 
Cardinality:2 
Sub part:NULL 
Packed:NULL 
Null: 

Index type:BTREE 
Comment : 

5 rows in set (0.00 sec) 








通过 命令 SHOW INDEX FROM 可 以 观察 到 表 {( 上 有 4 个 索引 ， 分 别 为 
主键 索引 、c 列 上 的 辅助 索引 、b 列 的 前 100 字 节 构 成 的 辅助 索引 ， 以 及 
(a. c) 的 联合 辅助 索引 。 接 着 具体 曾 述 命令 SHOW INDEX 展 现 结果 中 
每 列 的 含义 。 


DTable: 索引 所 在 的 表 名 。 


DNon_uniqgue: 非 唯 一 的 索引 ， 可 以 看 到 primary key 是 0， 因 为 必 
须 是 唯一 的 。 


QKey name: 索引 的 名 字 ， 用 户 可 以 通过 这 个 名 字 来 执行 DROP 
INDEX. 


DSeq in index: 索引 中 该 列 的 位 置 ， 如 果 看 联合 索引 idx_a_c 束 比 
较 直观 了 。 








LColumn name: 索引 列 的 名 称 。 


DCollation: 列 以 什么 方式 存储 在 索引 中 。 可 以 是 A 或 NULL。 
B+ 树 索引 总 是 A， 即 排序 的 。 如 果 使 用 了 Heap 存 储 引 擎 ， 并 且 建 立 了 
Hash 索 引 ， 这 里 就 会 显示 NULL 了 。 因 为 Hash 根 据 Hash 桶 存放 索引 数 
据 ， 而 不 是 对 数据 进行 排序 。 


DCardinality: 非常 关键 的 值 ， 表 示 索 引 中 唯一 值 的 数目 的 估计 
值 。Cardinality 表 的 行 数 应 尽 可 能 接近 1， 如 采 非 常 小 ， 那 么 用 户 需要 考 
虑 是 否 可 以 删除 此 索引 。 


ODSub part: 是 否 是 列 的 部 分 被 索引 。 如 果 看 idx_b 这 个 索引 ， 这 里 
显示 100， 表 示 只 对 b 列 的 前 100 字 符 进 行 索引 。 如 果 索 引 整 个 列 ， 则 该 
字段 为 NULL 。 

口 Packed: 关键 字 如 何 被 压缩 。 如 果 没 有 被 压缩 ， 则 为 NULL 。 


DNull: 是 否 索引 的 列 含 有 NULL 值 。 可 以 看 到 idx_ b 这 里 为 Yes， 
因为 定义 的 列 b 人 允许 NULL 值 。 


DIndex_type: 索引 的 类 型 。InnoDB 存 储 引 擎 只 文 持 B+ 树 索引 ， 所 
以 这 里 显示 的 都 是 BTREE。 








OComment: 注释 。 


Cardinality 值 非常 关键 ， 优 化 器 会 根据 这 个 值 来 判断 是 否 使 用 这 个 
索引 。 但 是 这 个 值 并 不 是 实时 更 新 的 ， 即 并 非 每 次 索引 的 更 新 都 会 更 新 
该 值 ， 因 为 这 样 代价 太 大 了 。 因 此 这 个 值 是 不 太 准 确 的 ， 只 是 一 个 大 概 
的 值 。 上 面 显示 的 结果 主键 的 Cardinality 为 2， 但 是 很 显然 我 们 的 表 中 有 
4 条 记录 ， 这 个 值 应 该 是 4。 如 果 需 要 更 新 索引 Cardinality 的 信息 ， 可 以 
使 用 ANALYZE TABLE 命 令 ， 如 : 














mysql>analyze table t\G; 

JOOOOEOOOOOE ER OOOOOOOOIOOOOHOR] | pj FIGS ICICI III III III Ie 
Table:mytest.t 

Op: analyze 

Msg_type:status 

Msg text:0| 

1r in (0.01 C) 

ysq1- show dex t\G 


FOI IO IO ICICI GIGI IG IO IOIGR ppt IO IOI OCR ICR TOR oe Re CR IORI Ie 





这 时 的 Cardinality 值 就 对 了 。 不 过 ， 在 每 个 系统 上 可 能 得 到 的 结果 
不 一 样 ， 因 为 ANALYZE TABLE 现 在 还 存在 一 些 问题 ， 可 能 会 影响 最 后 
得 到 的 结果 。 另 一 个 问题 是 MySQL 数 据 库 对 于 Cardinality 计 数 的 问题 ， 
在 运行 一 段 时 间 后 ， 可 能 会 看 到 下 面 的 结果 : 





FOI IIIT ICICI ICICI] c py CRI KG ROO KO ROIG ROIG KO RIOR 





Cardinality 为 NULL， 在 某 些 情况 下 可 能 会 发 生 索 引 建立 了 却 没 有 用 
到 的 情况 。 或 者 对 两 条 基本 一 样 的 语句 执行 EXPLAIN， 但 是 最 终 出 来 
的 结果 不 一 样 : 一 个 使 用 索引 ， 另 外 一 个 使 用 全 表 扫 描 。 这 时 最 好 的 解 
决 办 法 就 是 做 一 次 ANALYZE TABLE 的 操作 。 因 此 我 建议 在 一 个 非 高 峰 
时 间 ， 对 应 用 程序 下 的 几 张 核心 表 做 ANALYZE TABLE 操 作 ， 这 能 使 优 
化 器 和 索引 更 好 地 为 你 工作 。 


2.Fast Index Creation 

MySQL 5.5 版 本 之 前 〈 不 包括 5.5) 存在 的 一 个 普遍 被 人 诉 病 的 问题 
是 MySQL 数 据 库 对 于 索引 的 添加 或 者 删除 的 这 类 DDL 操 作 ，MySQL 数 
据 库 的 操作 过 程 为 : 


口 首 先 创建 一 张 新 的 临时 表 ， 表 结构 为 通过 命令 ALTER TABLE 新 
定义 的 结构 。 


口 然后 把 原 表 中 数据 导入 到 临时 表 。 
口 接着 删除 原 表 。 
口 最 后 把 临时 表 重 名 为 原来 的 表 名 。 








可 以 发 现 ， 车 用 户 对 于 一 张大 表 进 行 索 引 的 添加 和 删除 操作 ， 那 么 
这 会 需要 很 长 的 时 间 。 更 关键 的 是 ， 知 有 大 量 事务 需要 访问 正在 被 修改 
的 表 ， 这 意味 着 数据 库 服务 不 可 用 。 而 这 对 于 Microsoft SQL Server 或 
p um 的 DBA 来 说 ，MySQL 数 据 库 的 索引 维护 始终 让 他 们 感觉 非 
T 


InnoDB 存 储 引 擎 从 InnoDB 1.0.x 版 本 开始 支持 一 种 称 为 Fast Index 
Creation 〈 快 速 索引 创建 ) 的 索引 创建 方式 简称 FIC。 


对 于 辅助 索引 的 创建 ，InnoDB 人 存储 引擎 会 对 创建 索引 的 表 加 上 一 
个 S 锁 。 在 创建 的 过 程 中 ， 不 需要 重建 表 ， 因 此 速度 较 之 前 提高 很 多 ， 
并 且 数 据 库 的 可 用 性 也 得 到 了 提高 。 删 除 辅助 索引 操作 就 更 简单 了 ， 
InnoDB 存 储 引 擎 只 需 更 新 内 部 视图 ， 并 将 辅助 索引 的 空间 标记 为 可 
用 ， 同 时 删除 MySQL 数 据 库 内 部 视图 上 对 该 表 的 索引 定义 即 可 。 


这 里 需要 特别 注意 的 是 ， 临 时 表 的 创建 路 径 是 通过 参数 tmpdir 进 行 
设置 的 。 用 户 必须 保证 tmpdir 有 足够 的 空间 可 以 存放 临时 表 ， 仍 则 会 导 
致 创 建 索 引 失 败 。 


由 于 FIC 在 索引 的 创建 的 过 程 中 对 表 加 上 了 S 锁 ， 因 此 在 创建 的 过 程 
中 只 能 对 该 表 进 行 读 操 作 ， 知 有 大 量 的 事务 需要 对 目标 表 进 行 写 操作 ， 
那么 数据 库 的 服务 同样 不 可 用 。 此 外 ，FIC 方 式 只 限定 于 辅助 索引 ， 对 
于 主键 的 创建 和 删除 同样 需要 重建 一 张 表 。 





























3.Online Schema Change 


Online Schema Change (在 线 架 构 改 变 ， 人 简称 0SC)〉 最 早 是 由 
Facebook 实 现 的 一 种 在 线 执行 DDL 的 方式 ， 并 广泛 地 应 用 于 Facebook 的 
MySQL 数 据 库 。 所 谓 “ 在 线 ” 是 指 在 事务 的 创建 过 程 中 ， 可 以 有 读 写 事务 
对 表 进 行 操作 ， 这 提高 了 原 有 MySQL 数 据 库 在 DDL 操 作 时 的 并 发 性 。 


Facebook 采 用 PHP 脚 本 来 现实 OSC， 而 并 不 是 通过 修改 InnoDB 存 储 
引擎 源码 的 方式 。OSC 最 初 由 Facebook 的 员工 Vamsi Ponnekanti 开 发 。 此 
外 ，OSC 借 鉴 了 开源 社区 之 前 的 工具 The openarkkit toolkit oak-online- 
alter-table。 实 现 OSC 步 又 如 下 : 


Dinit， 即 初始 化 阶段 ， 会 对 创建 的 表 做 一 些 验证 工作 ， 如 检查 表 
KE A ERE, ce EUR dS BUE PP SESS. 











DcreateCopyTable， 创 建 和 原始 表 结 构 一 样 的 新 表 。 


DlalterCopyTable: 对 创建 的 新 表 进 行 ALTER TABLE 操 作 ， 如 添加 
索引 或 列 等 。 


DcreateDeltasTable， 创 建 deltas 表 ， 该 表 的 作用 是 为 下 一 步 创建 的 
触发 器 所 使 用 。 之 后 对 原 表 的 所 有 DML 操 作 会 被 记录 到 


createDeltasTable'# 。 


DcreateTriggers， 对 原 表 创 建 INSERT、UPDATE、DELETE 操 作 的 
触发 器 。 触 发 操作 产生 的 记录 被 写 入 到 deltas 表 。 


DstartSnpshotXact， 开 始 OSC 操 作 的 事务 。 


DselectTableIntoOutfile， 将 原 表 中 的 数据 写 入 到 新 表 。 为 了 减少 对 
原 表 的 锁定 时 间 ， 这 里 通过 分 片 〈chunked) 将 数据 输出 到 多 个 外 部 文 
件 ， 然 后 将 外 部 文件 的 数据 导入 到 copy 表 中 。 分 片 的 大 小 可 以 指定 ， 默 
认 值 是 500 000。 


口 dropNCIndexs， 在 导入 到 新 表 前 ， 删 除 新 表 中 所有 的 辅助 索引 。 
DQloadCopyTable， 将 导出 的 分 片 文件 导入 到 新 表 。 


DreplayChanges， 将 OSC 过 程 中 原 表 DML 操 作 的 记录 应 用 到 新 表 
中 ， 这 些 记录 被 保存 在 deltas 表 中 。 


DrecreateNCIndexes， 重 新 创建 辅助 索引 。 


DreplayChanges， 再 次 进行 DML 日 志 的 回放 操作 ， 这 些 日 志 是 在 上 
述 创建 辅助 雪 引 中 过 程 中 新 产生 的 日 志 。 


口 swapTables， 将 原 表 和 新 表 交 换 名 字 ， 整 个 操作 需要 锁定 2 张 
E UE SS 由 于 改名 是 一 个 很 快 的 操作 ， 因 此 阻塞 的 时 
间 非 常 短 。 


上 述 只 是 简单 介绍 了 OSC 的 实现 过 程 ， 实 际 脚本 非常 复杂 ， 仪 OSC 
的 PHP 核 心 代码 就 有 2200 多 行 ， 用 到 的 MySQL ”InnoDB 的 知识 点 非常 
多 ， 建 议 DBA 和 数据 库 开 发 人 员 尝 试 进行 阅读 ， 这 有 助 于 更 好 地 理解 
InnoDB 存 储 引 擎 的 使 用 。 








由 于 OSC 只 是 一 个 PHP 脚 本 ， 因 此 其 有 一 定 的 局 限 性 。 例 如 其 要 求 
进行 修改 的 表 一 定 要 有 主键 ， 且 表 本 喘 不 能 存在 外 键 和 触发 堪 。 此 外 ， 
在 进行 OSC 过 程 中 ， 人 允许 SET sql bin log=0， 因 此 所 做 的 操作 不 会 同步 
slave 服 务 器 ， 可 能 导致 主 从 不 一 致 的 情况 。 

4.Online DDL 

虽然 FIC 可 以 让 InnoDB 存 储 引 擎 避免 创建 临时 表 ， 从 而 提高 索引 创 
建 的 效率 。 但 正如 前 面 小 节 所 说 的 ， 索 引 创建 时 会 阻塞 表 上 的 DML 操 
作 。OSC 虽 然 解 决 了 上 述 的 部 分 问题 ， 但 是 还 是 有 很 大 的 局 限 性 。 
MySQL 5.6 版 本 开始 支持 Online DDL (在 线 数据 定义 ) 操作 ， 其 允许 辅 
助 索引 创建 的 同时 ， 还 允许 其 他 诸如 INSERT、UPDATE、DELETE 这 
类 DMI 操作， 这 极 大 地 提高 了 MySQL 数 据 库 在 生产 环境 中 的 可 用 性 。 


此 外 ， 不 仅 是 辅助 索引 ， 以 下 这 几 类 DDL 操 作 都 可 以 通过 “在 线 ” 的 
方式 进行 操作 : 


口 辅助 索引 的 创建 与 删除 

口 改变 自 增长 值 

口 添加 或 删除 外 键 约束 

口 列 的 重 命名 

通过 新 的 ALTER TABLE 语 法 ， 用 户 可 以 选择 索引 的 创建 方式 : 











ALTER TABLE tbl name 
|ADD(INDEX|KEY) [index name] 
il x type](index col name,...)[index option]... 

ALGORITHM[=] {DEFAULT | INPLACE | COPY 

LOCK[=] {DEFAULT | NONE | SHARED | EXCLUSIVE} 


ALGORITHM 指 定 了 创建 或 删除 索引 的 算法 ，COPY 表 示 按 照 
MySQL 5.1 版 本 之 前 的 工作 模式 ， 即 创建 临时 表 的 方式 。INPLACE 表 示 
索引 创建 或 删除 操作 不 需要 创建 临时 表 。DEFAULT 表 示 根 据 参 数 
old_alter_table 来 判断 是 通过 INPLACE 还 是 COPY 的 算法 ， 该 参数 的 默认 
值 为 OFF， 表 示 末 用 INPLACE 的 方式 ， 如 : 


mysql>SELECT@@version\G; 


1 row in set(0.00 sec) 

mysql1- SHOW VARIABLES LIKE'old alter table'*G; 

FOI TO IO TOTO IOI TOR TO IK IC 1.rOw****eeeeeeeeeeeeeeeeeemmIariable name:old_alter_table 
Value : OFF 
1 row in set(0.00 sec) 


" LOCK 部 分 为 索引 创建 或 删除 时 对 表 添 加 锁 的 情况 ， 可 有 的 选择 


(1) NONE 


执行 索引 创建 或 者 删除 操作 时 ， 对 目标 表 不 添加 任何 的 锁 ， 即 事务 
A COUTE ARRP. PACES n] DAR ABCA 


(2) SHARE 


这 和 之 前 的 FIC 类 似 ， 执 行 索引 创建 或 删除 操作 时 ， 对 目标 表 加 上 
一 个 s 锁 。 对 于 并 发 地 读 事 务 ， 依 然 可 以 执行 ， 但 是 过 到 写 事务 ， 束 会 
REESE TEER 如 果 存 储 引 擎 不 支持 SHARE 模 式 ， 会 返回 一 个 错误 信 


(3) EXCLUSIVE 


在 EXCLUSIVE 模 式 下 ， 执 行 索引 创建 或 删除 操作 时 ， 对 目标 表 加 
上 一 个 X 锁 。 读 写 事 务 都 不 能 进行 ， 因 此 会 阻塞 所 有 的 线程 ， 这 和 
D URS 但 是 不 需要 像 COPY 方 式 那样 创建 一 
张 临 时 表 。 


(4) DEFAULT 


DEFAULT 模 式 首 先 会 判断 当前 操作 是 否 可 以 使 用 NONE 模 式 ， 若 
不 能 ， 则 判断 是 否 可 以 使 用 SHARE 模 式 ， 最 后 判断 是 否 可 以 使 用 
EXCLUSIVE 模 式 。 也 就 是 说 DEFAULT 会 通过 判断 事务 的 最 大 并 发 性 来 
判断 执行 DDL 的 模式 。 


InnoDB 存 储 引 擎 实现 Online DDL 的 原理 是 在 执行 创建 或 者 删除 操 
作 的 同时 ， 将 INSERT、UPDATE、DELETE 这 类 DML 操 作 日 志 写 入 到 
个 缓存 中 。 竺 完成 索引 创建 后 再 将 重 做 应 用 到 表 上 ， 以 此 达到 数据 的 
一 致 性 。 这 个 缓存 的 大 小 由 参数 innodb_online_alter_ log_max_size 控 制 ， 
默认 的 大 小 为 128MB。 知 用 户 更 新 的 表 比 较 大 ， 并 且 在 创建 过 程 中 伴 有 











大 量 的 写 事务 ， 如 遇 到 innodb_online_alter_ log_max_size 的 空间 不 能 存放 
日 志 时 ， 会 抛 出 类 似 如 下 的 错误 : 





Error:1799SQLSTATE:HYOO0(ER INNODB ONLINE LOG TOO BIG) 
Message:Creating index'idx aaa'required more than'innodb online alter log max size'bytes of modification log.Please try 
again. 





对 于 这 个 错误 ， 用 户 可 以 调 大 参数 
innodb online alter log_max_size， 以 此 获得 更 大 的 日 志 绥 存 空 间 。 此 
外 ， 还 可 以 设置 ALTER TABLE 的 模式 为 SHARE， 这 样 在 执行 过 程 中 不 
会 有 写 事务 发 生 ， 因 此 不 需要 进行 DML 日 志 的 记录 。 


需要 特别 注意 的 是 ， 由 于 Online DDL 在 创建 索引 完成 后 再 通过 重 做 
日 志 达 到 数据 库 的 最 终 一 致 性 ， 这 意味 着 在 索引 创建 过 程 中 ，SQL 优 化 
髓 不 会 选择 正在 创建 中 的 索引 。 








5.5 Cardinality 值 


5.5.1 什么 是 Cardinality 


并 不 是 在 所 有 的 碍 询 条 件 中 出 现 的 列 都 需要 添加 索引 。 对 于 什么 时 
候 添 加 B+ 树 索 引 ， 一 般 的 经 验 是 ， 在 访问 表 中 很 少 一 部 分 时 使 用 B+ 树 
索引 才 有 意义 。 对 于 性 别 字 段 、 地 区 字段 、 类 型 字段 ， 它 们 可 取 值 的 范 
围 很 小 ， 称 为 低 选择 性 。 如 : 

















SELECT*FROM student WHERE sex='M' 








FRIEDE AW, RIBURRUTR ESI TP RUM. Fe LE EXSSQL 
语句 得 到 的 结果 可 能 是 该 表 50% 的 数据 (假设 男女 比例 1 : 1) ， 这 时 添 
加 B+ 树 索引 是 完全 没有 必要 的 。 相 反 ， 如 果 茶 个 字段 的 取 值 范围 很 
广 ， 几 乎 没有 重复 ， 即 属于 高 选择 性 ， 则 此 时 使 用 B+ 树 索引 是 最 适合 
的 。 例 如 ， 对 于 姓名 字段 ， 基 本 上 在 一 个 应 用 中 不 允许 重 名 的 出 现 。 


怎样 查看 索引 是 否 是 高 选择 性 的 呢 ? 可 以 通过 SHOW INDEX 结果 
中 的 列 Cardinality 来 观察 。Cardinality 值 非常 关键 ， 表 示 索 引 中 不 重复 记 
录 数 量 的 预 估 值 。 同 时 需要 注意 的 是 ，Cardinality 是 一 个 预 估 值 ， 而 不 
是 一 个 准确 值 ， 基 本 上 用 户 也 不 可 能 得 到 一 个 准确 的 值 。 在 实际 应 用 
中 ，Cardinality/n_rows_in_table 应 尽 可 能 地 接近 1。 如 果 非 党 小 ， 那 么 用 
户 需 要 考虑 是 否 还 有 必要 创建 这 个 索引 。 故 在 访问 高 选择 性 属性 的 字段 
eee 对 这 个 字段 添加 B+ 树 索引 是 非常 有 
ip Je Us 
































SELECT*FROM member WHERE usernick-'David' 








表 member 大 约 有 500 万 行 数据 。usernick 字 段 上 有 一 个 唯一 的 索引 。 
这 时 如 果 查 找 用 户 名 为 David 的 用 户 ， 将 会 得 到 如 下 的 执行 计划 : 





mysql>EXPLAIN SELECT*FROM member 

->WHERE usernick='David'\G; 

JOOOOODIOOOOOOOOOOOOOOOOOOR] | p yy AICI III ICICI III ICI III Ie 
id:i 

select type:SIMPLE 

table:member 

e:const 


ref:const 

rows:1 

Extra: 

1 row in set(0.00 sec) 





可 以 看 到 使 用 了 usernick 这 个 索引 ， 这 也 符合 之 前 提 到 的 高 选择 
性 ， 即 SQL 语句 选取 表 中 较 少 行 的 原则 。 





5.5.2 InnoDB/f fi 7| SÉ ff) CardinalityZit il 


上 上 一 小 节 介 绍 了 Cardinality 的 重要 性 ， 并 且 告 诉 读者 Cardinality 表 示 
选择 性 。 建 立 索 引 的 前 提 是 列 中 的 数据 是 高 选择 性 的 ， 这 对 数据 库 来 说 
才 具 有 实际 意义 。 然 而 数据 库 是 怎样 来 统计 Cardinality 信 息 的 呢 ? 因为 
MySQL 数 据 库 中 有 各 种 不 同 的 存储 引擎 ， 而 每 种 存储 引擎 对 于 B+ 树 索 
的 实现 又 各 不 相同 ， 所 以 对 Cardinality 的 统计 是 放 在 存储 引擎 层 进行 

















此 外 需要 考虑 到 的 是 ， 在 生产 环境 中 ， 索 引 的 更 新 操作 可 能 是 非常 
频繁 的 。 如 果 每 次 索引 在 发 生 操 作 时 束 对 其 进行 Cardinality 的 统计 ， 那 
么 将 会 给 数据 库 带 来 很 大 的 负担 。 另 外 需要 考虑 的 是 ， 如 果 一 张 表 的 数 
据 非 常 大 ， 如 一 张 表 有 50G 的 数据 ， 那 么 统计 一 次 Cardinality 信 息 所 需 
要 的 时 间 可 能 非常 长 。 这 在 生产 环境 下 ， 也 是 不 能 接受 的 。 因 此 ， 数 据 
库 对 于 Cardinality 的 统计 都 是 通过 采样 (Sample) 的 方法 来 完成 的 。 


在 InnoDB 存 储 引擎 中 ，Cardinality 统 计 信 息 的 更 新 发 生 在 两 个 操作 
H: INSERT 和 UPDATE。 根 据 前 面 的 叙述 ， 不 可 能 在 每 次 发 生 INSERT 
和 UPDATE 时 就 去 更 新 Cardinality 信 息 ， 这 样 会 增加 数据 库 系 统 的 负 
荷 ， 同 时 对 于 大 表 的 统计 ， 时 间 上 也 不 允许 数据 库 这 样 去 操作 。 因 此 ， 
InnoDB 存 储 引 擎 内 部 对 更 新 Cardinality 信 息 的 策略 为 : 


口 表 中 1/16 的 数据 已 发 生 过 变化 。 
Llstat modified counter- 2 000 000 000. 


第 一 种 策略 为 自从 上 次 统计 Cardinality 信 息 后 ， 表 中 1/16 的 数据 已 
经 发 后 过 变化 ， 这 时 需要 更 新 Cardinality 信 息 。 第 二 种 情况 考虑 的 是 ， 
如 果 对 表 中 某 一 行 数据 频繁 地 进行 更 新 操作 ， 这 时 表 中 的 数据 实际 并 没 
有 增加 ， 实 际 发 生变 化 的 还 是 这 一 行 数据 ， 则 第 一 种 更 新 策略 就 无 法 适 
用 这 这 种 情况 。 故 在 InnoDB 存 储 引 擎 内 部 有 一 个 计数 器 
stat_modified_counter， 用 来 表示 发 生变 化 的 次 数 ， 当 
stat_modified_counter 大 于 2 000 000 000 时 ， 则 同样 需要 更 新 Cardinality 


= 
Ei 4o 


接 独 考虑 InnoDB 存 储 引 擎 内 部 是 怎样 来 进行 Cardinality 信 息 的 统计 
和 更 新 操作 的 呢 ? 同样 是 通过 采样 的 方法 。 黑 认 ImnoDB 存 储 引 擎 对 8 个 

















叶子 节点 〈Leaf Page) 进行 采用 。 采 样 的 过 程 如 下 : 
口 取 得 B+ 树 索引 中 叶子 节点 的 数量 ， 记 为 A。 


口 随机 取得 B+ 树 索引 中 的 8 个 叶子 节点 。 统 计 每 个 页 不 同 记 录 的 个 
数 ， 即 为 P1，P2，...，P8。 








口 根 据 采 样 信息 给 出 Cardinality 的 预 估 值 : Cardinality= (P1+P2+... 
+P8) *A/8。 


通过 上 述 的 说 明 可 以 发 现 ， 在 InnoDB 存 储 引 擎 中 ，Cardinality 值 是 
通过 对 8 个 时 子 节点 预 估 而 得 的 ， 不 是 一 个 实际 精确 的 值 。 再 者 ， 每 次 
对 Cardinality 值 的 统计 ， 都 是 通过 随机 取 8 个 时 子 节点 得 到 的 ， 这 同时 又 
暗示 了 男 一 个 Cardinality 现 象 ， 即 每 次 得 到 的 Cardinality 值 可 能 是 不 同 
的 。 如 : 








SHOW INDEX FROM OrderDetails 





上 述 这 人 句 SQL 语 句 会 触发 MySQL 数 据 库 对 于 Cardinality 值 的 统计 ， 
第 一 次 运行 得 到 的 结果 如 图 5-20 所 示 。 
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图 5-20 第 一 次 运行 SHOW INDEX FROM OrderDetails 的 结 


在 上 述 测试 过 程 中 ， 并 没有 通过 INSERT、UPDATE 这 类 操作 来 改 
变 表 OrderDetails 中 的 内 容 ， 但 是 当 第 二 次 再 运行 SHOW INDEX FROM 
语句 时 ，Cardinality 值 还 是 会 发 生变 化 ， 如 图 5-21 所 示 。 
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图 5-21 第 二 次 运行 SHOW INDEX FROM OrderDetails 的 结果 


可 以 看 到 ， 第 二 次 运行 SHOW INDEX FROM 语句 时 ， 表 
OrderDetails 中 索引 的 Cardinality 值 都 发 生 了 变化 ， 虽 然 表 OrderDetails 本 
身 并 没有 发 生 任 何 的 变化 ， 但 是 ， 由 于 Cardinality 是 对 随机 取 8 个 叶子 节 
点 进行 分 析 ， 所 以 即使 表 没 有 发 生变 化 ， 用 户 观察 到 的 索引 Cardinality 
值 还 是 会 发 生变 化 ， 这 本 身 并 不 是 InnoDB 存 储 引 警 的 Bug， 只 是 随机 采 
样 而 导致 的 结 


当然 ， 有 一 种 情况 可 能 使 得 用 户 每 次 观察 到 的 索引 Cardinality 值 都 
征 一样 的 ， 那 就 是 表 足 够 小 ， 表 的 叶子 节点 数 小 于 或 者 等 于 8 个 。 这 时 
即使 随机 采样 ， 也 总 是 会 采取 到 这 些 页 ， 因 此 每 次 得 到 的 Cardinality 值 
是 相同 的 。 


在 InnoDB 1.2 版 本 之 前 ， 可 以 通过 参数 innodb_stats_sample_pages 用 
来 设置 统计 Cardinality 时 每 次 玉 样 页 的 数量 ， 默 认 值 为 8。 同 时 ， 参 数 
innodb_stats_method 用 来 判断 如 何 对 竺 索引 中 出 现 的 NULL 值 记录 。 访 
参数 默认 值 为 nulls equal， 表 示 将 NULL 值 记录 视 为 相等 的 记录 。 其 有 
效 值 还 有 nulls_unequal，nulls_ignored， 分 别 表示 将 NULL 值 记录 视 为 不 
同 的 记录 和 忽略 NULL 值 记录 。 例 如 茶 页 中 索引 记录 为 NULL、NULL、 
1、2、2、3、3、3， 在 参数 innodb_stats_method 的 默认 设置 下 ， 该 页 的 
Cardinality 为 4， 知 参数 innodb_stats_method 为 nulls_unequal， 则 该 页 的 
Caridinality 为 5;， 若 参数 innodb_stats_method 为 nulls_ignored， 则 
Cardinality 为 3。 











当 执 行 SQL 语句 ANALYZE TABLE. SHOW TABLE STATUS, 


SHOW INDEX 以 及 访问 INFORMATION_SCHEMA 架 构 下 的 表 TABLES 
和 STATISTICS 时 会 导致 InnoDB 存 储 引 擎 去 重新 计算 索引 的 Cardinality 
值 。 奉 表 中 的 数据 量 非常 大 ， 并 且 表 中 存在 多 个 辅助 索引 时 ， 执 行 上 述 
这 些 操作 可 能 会 非常 慢 。 虽 然 用 户 可 能 并 不 希望 去 更 新 Cardinality 值 。 


InnoDB1.2 版 本 提供 了 更 多 的 参数 对 Cardinality 统 计 进 行 设置 ， 这 些 
参数 如 表 5-3 所 示 。 


sr 
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innodb stas persistent 


inodo stats on metadata 


$53 InnoDB 1255858] 
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icm ANALYZE TABLE 计算 得 到 的 Cardinalty [E TCR ER 
上 , dos CRE RNAP LL D ERE RU Cardinality 
fi, PE MySQL BEER. Wh Ro Uo CREATE 
TABLE fl ALTER TABLE f; STATS PERSISTENT Je feat 
tl. 
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ab it a SHOW TABLE STATUS, SHOW INDEX Jk if 
INFORMATION SCHEMA AE] P TABLES fl STATISTICS, j 
从 要 重新 计算 索引 的 Cardinality fj 

AU: OFF 

fi D A inodo stats persistent E E AON, WA AEK ANALYZE 


innodh stats persistent sample pages |TABLE jr Cardinality EM CHER: 


jus 20 
次 参数 用 来 取代 之 前 本 的 参数 jnnodb stats. sample pags, Un ij 


innodb stas transient sample pages ER Ci, 


AA: 8 


5.6 B+ 树 索 引 的 使 用 


5.6.1 不 同 应 用 中 B+ 树 索 引 的 使 用 


在 了 解 了 B+ 树 索引 的 本 质 和 实现 后 ， 下 一 个 需要 考虑 的 问题 是 怎 
样 正 确 地 使 用 B+ 树 索引 ， 这 不 是 一 个 简单 的 问题 。 这 里 所 总 结 的 可 能 
并 不 适用 于 所 有 的 应 用 场合 。 我 所 能 做 的 只 是 概括 一 个 大 概 的 方向 。 在 
实际 的 生产 环境 使 用 中 ， 每 个 DBA 和 开发 人 员 ， 还 是 需要 根据 自己 的 具 
体 生产 环境 来 使 用 索引 ， 并 观察 索引 使 用 的 情况 ， 判 断 是 人 否 需要 添加 过 
引 。 不 要 盲从 任何 人 给 你 的 经 验 意 见 ，Think Different. 


根据 第 1 章 的 介绍 ， 用 户 已 经 知道 数据 库 中 存在 两 种 类 型 的 应 用 ， 
OLTP 和 OLAP 应 用 。 在 OLTP 应 用 中 ， 碍 询 操作 只 从 数据 库 中 取得 一 小 
部 分 数据 ， 一 般 可 能 都 在 10 条 记录 以 下 ， 甚 至 在 很 多 时 候 只 取 1 条 记 
录 ， 如 根据 主键 值 来 取得 用 户 信息 ， 根 据 订 单 号 取得 订单 的 详细 信息 ， 
这 都 是 典型 OLTP 应 用 的 查询 语句 。 在 这 种 情况 下 ，B+ 树 索引 建立 后 ， 
对 该 索引 的 使 用 应 该 只 是 通过 该 索引 取得 表 中 少 部 分 的 数据 。 这 时 建立 
a a soin uid a de due 


对 于 OLAP 应 用 ， 情 况 可 能 束 稍 显 复 杂 了 。 不 过 概括 来 说 ， 在 
OLAP 应 用 中 ， 都 需要 访问 表 中 大 量 的 数据 ， 根 据 这 些 数据 来 产生 查询 
的 结果 ， 这 些 查 询 多 是 面向 分 析 的 查询 ， 目 的 是 为 决策 者 提供 支持 。 如 
这 个 月 每 个 用 户 的 消费 情况 ， 销 售 额 同比 、 环 比 增长 的 情况 。 因 此 在 
OLAP 中 索引 的 添加 根据 的 应 该 是 宏观 的 信息 ， 而 不 是 微观 ， 因 为 最 终 
要 得 到 的 结果 是 提供 给 决策 者 的 。 例 如 不 需要 在 OLAP 中 对 姓名 字段 进 
行 索 引 ， 因 为 很 少 需要 对 单个 用 户 进 行 查询 。 但 是 对 于 OLAP 中 的 复杂 
查询 ， 要 涉及 多 张 表 之 间 的 联接 操作 ， 因 此 索引 的 添加 依然 是 有 意义 
的 。 但 是 ， 如 果 联 接 操 作 使 用 的 是 Hash Join， 那 么 索引 可 能 又 变 得 不 是 
非常 重要 了 ， 所 以 这 需要 DBA 或 开发 人 员 认 真 并 仔细 地 研究 自己 的 应 
用 。 不 过 在 OLAP 应 用 中 ， 通 常会 需要 对 时 间 字 上 段 进行 索引 ， 这 是 因为 
大 多 数 统计 需要 根据 时 间 维 度 来 进行 数据 的 科 选 。 







































































5.6.2 ”联合 索引 


联合 索引 是 指 对 表 上 的 多 个 列 进行 索引 。 前 面 讨论 的 情况 都 是 只 对 
表 上 的 一 个 列 进行 索引 。 联 合 索引 的 创建 方法 与 单个 索引 创建 的 方法 一 
样 ， 不 同 之 处 仅 在 于 有 多 个 索引 列 。 例 如 ， 以 下 代码 创建 了 一 张 表 ， 
FEARI idx a be KERI, KAKI a, b). 











CREATE TABLE t( 
a INT, 
b INT, 
PRIMARY KEY(a), 
KEY idx_a_b(a,b 
)ENGINE=INNODB 


那么 何 时 需要 使 用 联合 索引 呢 ? 在 讨论 这 个 问题 之 前 ， 先 来 看 一 下 
联合 索引 内 部 的 结果 。 从 本 质 上 来 说 ， 联 合 索 引 也 是 一 棵 B+ 树 ， 不 同 
的 是 联合 索引 的 键 值 的 数量 不 是 1， 而 是 大 于 等 于 2。 接 着 来 讨论 两 个 整 
型 列 组 成 的 联合 索引 ， 假 定 两 个 键 值 的 名 称 分 别 为 a、b， 如 图 5-22 所 
外。 








图 5-22 多 个 键 值 的 B+ 树 


从 图 5-22 可 以 观察 到 多 个 键 值 的 B+ 树 情况 。 其 实 和 之 前 讨论 的 单个 
键 值 的 B+ 树 并 没有 什么 不 同 ， 键 值 都 是 排序 的 ， 通 过 叶子 节点 可 以 逻 
辑 上 顺序 地 读 出 所 有 数据 ， 就 上 面 的 例子 来 说 ， 即 Gd, D. G, 
22. (2，1) 、 (2，4) 、 (3，1) 、 (3，2) 。 数 据 按 (a, b) 的 





顺序 进行 了 存放 。 


因此 ， 对 于 查询 SELECT*FROM TABLE WHERE a=xxx and 
b=xxx， 显 然 是 可 以 使 用 (a，b) 这 个 联合 索引 的 。 对 于 单个 的 a 列 查询 
SELECT*FROM TABLE WHERE a=xxx， 也 可 以 使 用 这 个 (a, b) 索 
引 。 但 对 于 b 列 的 查询 SELECT*FROM TABLE WHERE b=xxx， 则 不 可 
以 使 用 这 棵 B+ 树 索引 。 可 以 发 现时 子 节 点 上 的 b 值 为 1、2、1、4、1、 
2， 显 然 不 是 排序 的 ， 因 此 对 于 b 列 的 查询 使 用 不 到 Ca, b) RESI. 


联合 索引 的 第 二 个 好 处 是 已 经 对 第 二 个 键 值 进行 了 排序 处 理 。 例 
如 ， 在 很 多 情况 下 应 用 程序 都 需要 查询 某 个 用 户 的 购物 情况 ， 并 按照 时 
间 进 行 排 夺 ， 最 后 取出 最 近 三 次 的 购买 记录 ， 这 时 使 用 联合 索引 可 以 避 
免 多 一 次 的 排序 操作 ， 因 为 索引 本 身 在 叶子 节点 已 经 排序 了 。 来 看 一 个 
例子 ， 首 先 根据 如 下 代码 来 创建 测试 表 buy_log: 




















CREATE TABLE buy. log( 
useri id INT UNSIGNED NOT NULL, 


VALUES(1, ' 2009-01-01'); 
VALUES(2, ' 2009-01-01'); 
VALUES(3, ' 2009-01-01'); 
VALUES(1, ' 2009-02-01'); 
VALUES(3, '2009-02-01'); 
VALUES(1, '2009-03-01'); 
VALUES(1, '2009-04-01'); 
ADD KEY(useri id); 

ADD KEY(userid,buy date); 


INSERT INTO ba uy. 
INSERT INTO buy. 
ALTER TABLE buy. 
ALTER TABLE buy. 


88888888 








以 上 代码 建立 了 两 个 索引 来 进行 比较 。 两 个 索引 都 包含 了 userid 字 
段 。 如 果 只 对 于 userid 进 行 查询 ， 如 : 





SELECT*FROM buy log WHERE userid-2; 





则 优化 器 的 选择 为 如 图 5-23 所 示 。 





id select hpe tabe tpe possible keys — key  keylen — m mw — Era 





y) SIMPLE buy log ref useriduseid 2 useid 4 cod | 
图 5-23 查询 条 件 仅 为 userid 的 执行 计划 


从 图 5-23 中 可 以 发 现 ，possible_keys 在 这 里 有 两 个 索引 可 供 使 用 ， 
分 别 是 单个 的 userid 索 引 和 Cuserid, buy date) 的 联合 索引 。 但 是 优化 


aris IN wee A Gluserid, ALAA SIN Y nisu m B. HT 
以 理论 上 一 个 页 能 存放 的 记录 应 该 更 多 。 


接着 假定 要 取出 userid 为 1 的 最 近 3 次 的 购买 记录 ， 其 SQL 语句 如 
下 ， 执 行 计划 如 图 5-24 所 示 。 








SELECT*FROM buy_log 
WHERE userid=1 ORDER BY buy date DESC LIMIT 3 





id select ype — tale tpe possible keys key — ken mf mws Bte 





yi SINPLE ‘buy log userid userid 2 uei) 4 ot oj ing wher: Linc nder 
图 5-24 SQL 语句 的 执行 计划 


同样 的 ， 对 于 上 述 的 SQL 语句 既 可 以 使 用 userid 索 引 ， 也 可 以 使 用 
(userid, buy date) 索引 。 但 是 这 次 优化 器 使 用 了 Cuserid, 
buy date) 的 联合 索引 userid_2， 因 为 在 这 个 联合 索引 中 buy_date 已 经 排 
序 好 了 。 根 据 该 联合 索引 取出 数据 ， 无 顷 再 对 buy_date 做 一 次 额外 的 排 
序 操作 。 知 强制 使 用 userid 索 引 ， 则 执行 计划 如 网 5-25 所 示 。 








(id  selecthpe tabe tpe possible keys kk Bt 


» 1 SIMPLE bulog rm userid useid 4 cod Jj Using where; Using filesot 
图 5-25 强制 使 用 userid 索 引 的 执行 计划 


在 Extra 选 项 中 可 以 看 到 Using filesort， 即 需要 额外 的 一 次 排序 操作 
才能 完成 查询 。 而 这 次 显然 需要 对 列 buy_date 排 序 ， 因 为 索引 userid 中 的 
buy_date 是 未 排序 的 。 


正如 前 面 所 介绍 的 那样 ， 联 合 索 引 〈a，b) 其 实 是 根据 列 a、b 进 行 
排序 ， 因 此 下 列 语句 可 以 直接 使 用 联合 索引 得 到 结果 : 








SELECT. . .FROM TABLE WHERE a=xxx ORDER BY b 








然而 对 于 联合 索引 (a，b，c) 来 说 ， 下 列 语句 同样 可 以 直接 通过 
联合 索引 得 到 结 





SELECT...FROM TABLE WHERE a=xxx ORDER BY b 
SELECT...FROM TABLE WHERE a=xxx AND b=xxx ORDER BY c 








但 是 对 于 下 面 的 语句 ， 联 合 索引 不 能 直接 得 到 结果 ， 其 还 再 要 执行 
一 次 filesort 排 序 操作 ， 因 为 索引 Ca, c) 并 未 排序 : 








SELECT. . .FROM TABLE WHERE a=xxx ORDER BY c 





5.6.3 fem Rl 


InnoDB 存 储 引擎 支持 覆盖 索引 (covering index, BAKA S| Ati) ， 
即 从 辅助 索引 中 惑 可 以 得 到 查询 的 记录 ， 而 不 需要 查询 聚集 索引 中 的 记 
录 。 使 用 覆盖 索引 的 一 个 好 处 是 辅助 索引 不 包含 整 行 记录 的 所 有 信息 ， 
故 其 大 小 要 远 小 于 聚集 索引 ， 因 此 可 以 减少 大 量 的 IO 操作 。 


注意 ” 履 盖 索引 技术 最 早 是 在 InnoDB Plugin 中 完成 并 实现 。 这 意味 
着 对 于 InnoDB 版 本 小 于 1.0 的 ， 或 者 MySQL 数 据 库 版 本 为 5.0 或 以 下 的 ， 
InnoDB 存 储 引 擎 不 文 持 履 盖 索 引 特 性 。 


对 于 InnoDB 存 储 引 擎 的 辅助 索引 而 言 ， 由 于 其 包含 了 主键 信息 
因此 其 叶子 节 ado e (primary — keyl, primary key2, ..., 
a 2 . PW, PF BE ALATA ALI es deals 

HTJ: 

















SELECT key2 FROM table WHERE key1=xxx 

SELECT primary key2, key2 FROM table WHERE key1=X 

SELECT primary keyi,key2 FROM table WHERE keyi- 

SELECT primary key1,primary key2, key2 FROM tal ble E key1=xxx; 


28 ni ASIAN Nh feo] Set RB SA. EMT PE) 
节 创 建 的 表 buy_log， 要 进行 如 下 的 查询 : 











SELECT COUNT(*)FROM buy. 10g; 





InnoDB 存 储 引擎 并 不 会 选择 通过 查询 聚集 索引 来 进行 统计 。 由 于 
buy_log 表 上 还 有 辅助 索引 ， 而 辅助 索引 远 小 于 聚集 索引 ， 选 择 辅助 索 
引 可 以 减少 IO 操作 ， 故 优化 器 的 选择 为 如 图 5-26 所 示 。 

id select tpe — tabe — type possble keys key — key_len — ref, mws Eta 

1 SIMPLE — byhg index "^ seid 4 7 Using index 
图 5-26 COUNT (*) 操作 的 执行 计划 

通过 图 5-26 可 以 看 到 ，possible_keys 列 为 NULL， 但 是 实际 执行 时 优 








化 器 却 选 择 了 userid 索 引 ， 而 列 Extra 列 的 Using index 就 是 代表 了 优化 器 
BEAT T A aR S| ERE 


此 外 ， 在 通常 情况 下 ， 诸 如 Ca, bo 的 联合 索引 ， 一 般 是 不 可 以 选 
择 列 b 中 所 谓 的 碍 询 条 件 。 但 是 如 果 是 统计 操作 ， 并 且 是 履 盖 索引 的 ， 
则 优化 器 会 进行 选择 ， 如 下 述 语 句 : 

















SELECT COUNT(*)FROM buy log 
ERE buy date^-'2011-01-01'AND buy_date<'2011-02-01' 


4ebuy_log “(userid，buy_date〉 的 联合 索引 ， 这 里 只 根据 列 b 进 行 
条 件 查 询 ， 一 般 情 况 下 是 不 能 进行 该 联合 索引 的 ， 但 是 这 名 SQL 碍 询 是 
统计 操作 ， 并 且 可 以 利用 到 用 盖 索 引 的 信息 ， 因 此 优化 器 会 选择 该 联合 
索引 ， 其 执行 计划 如 图 5-27 所 示 。 











id select pe table type possible keys key key ref mws Bta 





p 1 SEE  byhg index wed 2 8 7 Using where: Using index 
图 5-27 利用 覆盖 索引 执行 统计 操作 


从 图 5-27 中 可 以 发 现 列 possible_keys 依 然 为 NULL， 但 是 列 key 为 
userid 2， 即 表示 (userid，buy_date〉 的 联合 索引 。 在 列 Extra 同 样 可 以 
发 现 Using index 提 示 ， 表 示 为 履 盖 索引 。 











5.6.4 优化 左 选 择 不 使 用 索引 的 情况 


在 某 些 情况 下 ， 当 执行 EXPLAIN 命 令 进行 SQL 语句 的 分 析 时 ， 会 发 
现 优化 器 并 没有 选择 索引 去 查找 数据 ， 而 是 通过 扫描 聚集 索引 ， 也 就 是 
直接 进行 全 表 的 扫描 来 得 到 数据 。 这 种 情况 多 发 生 于 范围 查找 、JOIN 链 
接 操 作 等 情况 下 。 例 如 : 











SELECT*FROM orderdetails 
RE orde ey pes nd orderid<102000; 





上 述 这 名 SQL 语句 查找 订单 号 大 于 10000 的 订单 详情 ， 通 过 命令 
SHOW INDEX FROM orderdetails， 可 观察 到 的 索引 如 图 5-28 所 示 。 
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图 。5-28 ” 表 orderdetails 的 索引 详情 


可 以 看 到 表 orderdetails 有 〈OrderID，ProductID ) 的 联合 主键 ， 此 
外 还 有 对 于 列 OrderID 的 单个 索引 。 寺 述 这 何 SQL 显 然 是 可 ! 以 通过 扫描 
OrderID 上 的 索引 进行 数据 的 查找 。 然 而 通过 EXPLAIN 命 令 ， 用 户 会 发 
现 优化 器 并 没有 按照 OrderID 上 的 索引 来 查找 数据 ， 如 图 5-29 所 示 。 





d edttpe tale pe possible keys key — kb md me ba 





p | SMPLE oeretals ange PRIMARY OrderD,OrdersOrder Deals. PRIMARY 4 [o — Using where 


图 5-29 上 述 苑 围 查 询 的 SQL 执行 计划 


在 possible_keys 一 列 可 以 看 到 查询 可 以 使 用 PRIMARY、OrderID、 
OrdersOrder_Details 三 个 索引 ， 但 是 在 最 后 的 索引 使 用 中 ， 优 化 器 选择 
了 PRIMARY 聚 集 索 引 ， 也 就 是 表 扫 描 (table scan) ， 而 非 OrderID 辅 助 
索引 扫描 (index scan) 。 


这 是 为 什么 呢 ? 原因 在 于 用 户 要 选取 的 数据 是 整 行 信息 ， 而 
OrderID 索 引 不 能 履 兰 到 我 们 要 碍 询 的 信息 ， 因 此 在 对 OrderID 索 引 查询 
到 指定 数据 后 ， 还 需要 一 次 书签 访问 来 得 找 整 行 数据 的 信息 。 虽 然 
OrderID 索 引 中 数据 是 顺序 存放 的 ， 但 是 再 一 次 进行 书签 查找 的 数据 则 
古 无 序 的 ， 因 此 变 为 了 磁盘 上 的 离散 读 操 作 。 如 采 要 求 访问 的 数据 量 很 
小 ， 则 优化 器 还 是 会 选择 辅助 索引 ， 但 是 当 访问 的 数据 后 整个 表 中 数据 
的 蛋 大 一 部 分 时 (一 般 是 20% 左 右 )， 优 化 器 会 选择 通过 聚集 索引 来 查 
找 数据 。 因 为 之 前 已 经 提 到 过 ， 顺 序 读 要 远 远 快 于 离散 读 。 


因此 对 于 不 能 进行 索引 履 盖 的 情况 ， 优 化 器 选择 辅助 索引 的 情况 
是 ， 通 过 辅助 索引 查找 的 数据 是 少量 的 。 这 是 由 当前 传统 机 械 人 硬盘 的 特 
性 所 诀 定 的 ， 即 利用 顺序 读 来 蔡 换 随机 读 的 查找 。 知 用 户 使 用 的 磁盘 是 
国 态 硬盘 ， 随 机 读 操 作 非 常 快 ， 同 时 有 足够 的 自信 来 确认 使 用 辅助 索引 
那么 可 以 使 用 关键 字 FORCE INDEX 来 强制 使 用 
| RI , H: 























SELECT*FROM orderdetails FORCE INDEX(OrderID) 
WHERE orderid>10000 and orderid<102000; 


这 时 的 执行 计划 如 图 5-30 所 示 。 





id select pe table bpe possible keys key keln o ms Bta 
y SIMPLE  ovderdetais range Order Onder 4 M) — sing where 
图 5-30 强制 使 用 辅助 索引 


5.6.5 ”索引 提示 


MySQL 数 据 库 支 持 索引 提示 (INDEX HINT) ， 显 式 地 告诉 优化 器 
使 用 哪个 索引 。 个 人 总 结 以 下 两 种 情况 可 能 需要 用 到 INDEX HINT: 


口 MySQL 数 据 库 的 优化 器 错误 地 选择 了 荣 个 索引 ， 导 致 SQL 语句 运 
行 的 很 慢 。 这 种 情况 在 最 新 的 MySQL 数 据 库 版 本 中 非常 非常 的 少见 。 
优化 需 在 绝 大 部 分 情况 下 工作 得 都 非常 有 效 和 正确 。 这 时 有 经 验 的 DBA 
E E 
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就 是 比较 耗 时 的 操作 。 这 时 DBA 或 开发 人 员 分 析 最 优 的 索引 选择 ， 通 过 
Index ”Hint 来 强制 使 优化 占 不 进行 各 个 执行 路 径 的 成 本 分 析 ， 和 直接 选择 
指定 的 索引 来 完成 得 询 。 


在 MySQL 数 据 库 中 mdex Hint 的 语法 如 下 : 


























tbl name[[AS]alias][index hint list] 

index hint list: 

index hint[,index hint]... 

i . hint: 

USE(INDEX | KEY} 

[{FOR{JOIN|ORDER BY|GROUP BY}]([index_list]) 
| IGNORE{ INDEX | KEY 

[{FOR{JOIN|ORDER BY|GROUP BY}](index_list) 
| FORCE{INDEX | KEY 

[{FOR{JOIN|ORDER BY|GROUP BY}](index_list) 
inde i 


st: 
index name[,index name]... 





接 独 来 看 一 个 例子 ， 首 移 根 据 如 下 代码 创建 测试 表 t， 并 填充 相应 





CREATE TABLE t( 
a INT, 


) ENGINE=INNODB; 

INSERT INTO t SELECT 1,1; 
INSERT INTO t SELECT 1,2; 
INSERT INTO t SELECT 2,3; 
INSERT INTO t SELECT 2,4; 
INSERT INTO t SELECT 1,2; 





然后 执行 如 下 的 SQL 语句 : 





SELECT*FROM t WHERE a=1 AND b-2; 





通过 EXPLAIN 命 令 得 到 如 图 5-31 所 示 的 执行 计划 。 


d — sepe — tb — type — posible keys key keylen mw me Bt 





jd) ME i Index merge ab ba 5» | Using intersect a) Using where: Using index 
图 5-31 SQL 语句 的 执行 计划 


图 5-31 中 的 列 possible_keys 显 示 了 上 述 SQL 语 句 可 使 用 的 索引 为 a， 
b， 而 实际 使 用 的 索引 为 列 Kkey 所 示 ， 同 样 为 a，b。 也 就 是 MySQL 数 据 库 
使 用 a，b 两 个 索引 来 完成 这 一 个 查询 。 列 Extra 提 示 的 Using 
intersect (b, a) 表示 根据 两 个 索引 得 到 的 结果 进行 求 交 的 数学 运算 ， 
最 后 得 到 结果 。 


如 果 我 们 使 用 USE INDEX 的 索引 提示 来 使 用 a 这 个 索引 ， 如 : 








SELECT*FROM t USE INDEX(a)WHERE a=1 AND b-2; 


那么 得 到 的 结果 如 图 5-32 所 示 。 









id sede table 
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图 5-32 使 用 USE INDEX 后 的 执行 计划 


可 以 看 到 ， 虽 然 我 们 指定 使 用 a 索引 ， 但 是 优化 器 实际 选择 的 是 通 
过 表 扫 描 的 方式 。 因 此 ，USE INDEX 只 是 告诉 优化 器 可 以 选择 该 索 
引 ， 实 际 上 优化 器 还 是 会 再 根据 自己 的 判断 进行 选择 。 而 如 果 使 用 
FORCE INDEX 的 索引 提示 ， 如 ; 














Using where 














SELECT*FROM t FORCE INDEX(a)WHERE a=1 AND b-2; 


则 这 时 的 执行 计划 如 图 5-33 所 示 。 





shed type table bpe possble keys key keln wo me bd 
jy) NPE | 时 à a i const J — Using where 
图 5-33 使 用 FORCE INDEX 后 的 执行 计划 
可 以 看 到 ， 这 时 优化 器 的 最 终 选 择 和 用 户 指定 的 索引 是 一 致 的 。 


此 ， 如 果 用 户 确 定 指 定 某 个 索引 来 完成 查询 ， 那 么 最 可 靠 的 是 使 用 
FORCE INDEX， 而 不 是 USE INDEX. 

















5.6.6 Multi-Range Read 优 化 


MySQL5.6 版 本 开始 支持 Multi-Range Read (MRR) 优化 。Multi- 
Range Read 优 化 的 目的 就 是 为 了 减少 磁盘 的 随机 访问 ， 并 且 将 随机 访问 
转化 为 较为 顺序 的 数据 访问 ， 这 对 于 IO-bound 类 型 的 SQL 得 询 语句 可 带 
来 性 能 极 大 的 提升 。Multi-Range ”Read 优化 可 适用 于 range，ref，eq_ref 
类 型 的 查询 。 


MRR 优 化 有 以 下 几 个 好 处 : 

口 MRR 使 数据 访问 变 得 较为 顺序 。 在 查询 辅助 索引 时 ， 首 先 根 据 
ELSE a LUN ott tope uU MUSEI 

口 减 少 缓冲 池 中 页 被 奉 换 的 次 数 。 

口 批量 处 理 对 键 值 的 查询 操作 。 


对 于 InnoDB 和 MyISAM 存 储 引 警 的 范围 查询 和 JOIN 查询 操作 ， 
MRR 的 工作 方式 如 下 : 


口 将 查询 得 到 的 辅助 索引 键 值 存放 于 一 个 缓存 中 ， 这 时 缓存 中 的 数 
据 是 根据 辅助 索引 键 值 排序 的 。 


口 将 缓存 中 的 键 值 根 据 RowID 进 行 排序 。 
口 根据 RowID 的 排序 顺序 来 访问 实际 的 数据 文件 。 


此 外 ， 知 InnoDB 存 储 引 擎 或 者 MyISAM 存 储 引 擎 的 缓冲 池 不 是 足够 
大 ， 即 不 能 存放 下 一 张 表 中 的 所 有 数据 ， 此 时 频繁 的 离散 读 操作 还 会 导 
致 缓存 中 的 页 被 蔡 换 出 缓冲 池 ， 然 后 又 不 断 地 被 读 入 缓冲 池 。 半 是 按照 
E 0 





























SELECT*FROM salaries WHERE salary- 10000 AND salary<40000; 


salary 上 有 一 个 辅助 索引 idx_s， 因 此 除了 通过 辅助 索引 查找 键 值 








外 ， 还 需要 通过 书签 查找 来 进行 对 整 行 数据 的 查询 。 当 不 启用 Mnulti- 

Range Read 特 性 时 ， 看 到 的 执行 计划 如 图 5-34 所 示 。 

gd ipe tabe bpe possble keys ke keln d me Bta 

p) SINPLE sais me d is 4 DM — Usngindex condtion 
图 5-34 不 启用 Multi-Range Read 的 执行 计划 


43 Ja FAMulit-Range Read 特 性 ， 则 除了 会 在 列 Extra 看 到 Using index 
condition 外 ， 还 会 看 见 Using MRR 选 项 ， 如 图 5-35 所 示 。 
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pil SIMPLE ae) me du ks d 23378 Using index condtion; Using MRR 
图 5-35 启用 Multi-Range Read 的 执行 计划 


" 而 在 实际 的 执行 中 会 体会 到 两 个 的 执行 时 间 差 别 非常 巨大 ， 如 表 5- 
4 用 不。 


54. GARR Mul-Range Read RE 
R8 (8) 
ARR] Mult-Rang Rea 40 
FE Mult-Range Read Qn 
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Ji Multi-Range Read 将 访问 数据 转化 为 顺序 后 查询 性 能 得 到 提高 。 





注意 “上述 测试 都 是 在 MySQL 数 据 库 司 动 后 直接 执行 SQL 查询 语 
E DOC ene 以 及 需要 查询 的 数据 并 不 包含 在 
Zeit 


此 外 ，Multi-Range ”Read 还 可 以 将 某 些 范围 得 询 ， 拆 分 为 键 值 对 ， 
以 此 来 进行 批量 的 数据 查询 。 这 样 做 的 好 处 是 可 以 在 拆 分 过 程 中 ， 直 接 
过 滤 一 些 不 符合 查询 条 件 的 数据 ， 例 如 : 


SELECT*FROM t 
WHERE key parti--1000 AND key_part1<2000 
AND key part2-10000; 


Xt Ckey partl, key_part2) 的 联合 索引 ， 因 此 索引 根据 
key_part1，key_part2 的 位 置 关系 进行 排序 。 奋 没有 Multi-Read Range, 
此 时 查询 类 型 为 Range，SQL 优 化 器 会 先 将 key_part1 大 于 1000 且 小 于 
2000 的 数据 都 取出 ， 即 使 key_part2 不 等 于 1000。 待 取出 行 数据 后 再 根据 
key_part2 的 条 件 进 行 过 滤 。 这 会 导致 无 用 数据 被 取出 。 如 果 有 大 量 的 数 
据 且 其 key_part2 不 等 于 1000， 则 局 用 MulitrRange ”Read 优 化 会 使 性 能 
巨大 的 提升 。 


firi: JH] f Multi-Range Read 优 化， 优化 右 会 先 将 查询 条 件 进行 拆 











分 ， 然 后 再 进行 数据 查询 。 就 上 述 查 询 语 句 而 言 ， 优 化 器 会 将 查询 条 件 
拆 分 为 (1000, 1000) , (1001, 1000) , (1002, 1000), ... 


(1999, 1000) ， 最 后 再 根据 这 些 拆 分 出 的 条 件 进 行 数 据 的 查询 。 
可 以 来 看 一 个 实际 的 例子 ， 查 询 如 下 : 





SELECT*FROM salaries 
WHERE(from date between'1986-01-01'AND'1995-01-01') 
AND(salary between 38000 and 40000); 


3:8 Hl f Multi-Range Read 优 化 ， 则 执行 计划 如 图 5-36 所 示 。 
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图 5-36 启用 Multi-Range Read 的 执行 计划 


表 salaries 上 有 对 于 salary 的 索引 idx_s， 在 执行 上 述 SQLi Hg IN, Al 
为 启用 了 Multi-Range ”Read 优 化， 所 以 会 对 查询 条 件 进 行 拆 分 ， 这 样 在 
列 Extra 中 可 以 看 到 Using MRR I . 


是 耕 启 用 Multi-Range ”Read 优 化 可 以 通过 参数 optimizer_switch 中 的 
标记 Cflag) 来 控制 。 当 marr 为 on 时 ， 表 示 局 用 Multi-Range Read h. 
mrr_cost_based 标 记 表 示 是 否 通过 cost based 的 万 式 来 选择 是 全 启用 mzrr。 
F mron, iun cost based 为 of， 则 总 是 启用 Multi-Range Read 
优化 。 例 如 ， 下 述 语句 可 以 将 Multi-Range ”Read 优化 总 是 设 为 开启 状 











mysql>SET@@optim. itch='mrr=on,mrr_cost_based=off'; 
Query OK,0 rows 人 00 se Had 





参数 read_rnd_buffer_size 用 来 控制 键 值 的 缓冲 区 大 小 ， 大 于 该 但 
则 执行 器 对 已 经 缓存 的 数据 根据 RowID 进 行 排序 ， 并 通过 RowID 来 
得 行 数据 。 该 值 默 认为 256K: 





mysql-SELECTQQread rnd buffer size*G; 
JOOOOOOOOOOOOOOOOOOOOOOOOOOR] I pj II ICICI III ICICI III III II I Ie 
oor ead rnd | er si 1262144 
row in SEU 00 dec 





5.6.7 Index Condition Pushdown (ICP) 优化 


和 Multi-Range Read—}¥, Index Condition Pushdown 同 样 是 MySQL 
5.6 开 始 支 持 的 一 种 根据 索引 进行 查询 的 优化 方式 。 之 前 的 MySQL 数 据 
库 版 本 不 支持 Index Condition Pushdown， 当 进行 索引 查询 时 ， 首 先 根据 
索引 来 查找 记录 ， 人 然后 再 根据 WHERE 条 件 来 过 滤 记 录 。 在 支持 Index 
Condition Pushdown 后 ，MySQL 数 据 库 会 在 取出 索引 的 同时 ， 判 断 是 否 
可 以 进行 WHERE 条 件 的 过 滤 ， 也 就 是 将 WHERE 的 部 分 过 滤 操 作 放 在 了 
存储 引 警 层 。 在 某 些 查询 下 ， 可 以 大 大 减少 上 层 SQL 层 对 记录 的 索取 
(fetch? ， 从 而 提高 数据 库 的 整体 性 能 。 


Index Condition Pushdown 优 化 文 持 range、ref、eq_ref、ref or null 
类 型 的 查询 ， 当 前 支持 MyISAM 和 InnoDB 存 储 引擎 。 当 优化 器 选择 
Index Condition Pushdown 优 化 时 ， 可 在 执行 计划 的 列 Extra 看 到 Using 
index condition 提 示 。 





























注意 NDB Cluster 存 储 引 擎 支持 Engine Condition Pushdown 优 化 。 
不 仅 可 以 进行 “TIndex” 的 Condition Pushdown， 也 可 以 文 持 非 索引 的 
Condition ”Pushdown， 不 过 这 是 由 其 引擎 本 身 的 特性 所 决定 的 。 男 外 在 
MySQL 5.1 版 本 中 NDB Cluster 存储 引擎 就 开始 文 持 Engine Condition 
Pushdown 优 化 。 


假设 某 张 表 有 联合 索引 (zip_code，1last_name，firset name), HÆ 
询 语句 如 下 : 





SELECT*FROM people 
HERE zipcode='95054' 
19 


IKE'%etrunia%' 
AND address LIKE'%Main Street%'; 





对 于 上 述 语句 ，MySQL 数 据 库 可 以 通过 索引 来 定位 zipcode 等 于 95 
054 的 记录 ， 但 是 索引 对 WHERE 条 件 的 lastname LIKE'%etrunia%' AND 
address LIKE'%Main Street%' 没 有 任何 帮助 。 若 不 支持 Index Condition 
Pushdown 优 化 ， 则 数据 库 需 要 先 通 过 索引 取出 所 有 zipcode 等 于 95 054 的 
记录 ， 然 后 再 过 滤 WHERE 之 后 的 两 个 条 件 。 


A Xx f¥Index Condition Pushdown 优 化 ， 则 在 索引 取出 时 ， 就 会 进行 
WHERE 条 件 的 过 滤 ， 然 后 再 去 获取 记录 。 这 将 极 大 地 提高 查询 的 效 








率 。 当 然 ，WHERE 可 以 过 滤 的 条 件 是 要 该 索引 可 以 覆盖 到 的 范围 。 来 
看 下 面 的 SQL 语句 : 


om date between'1986-01-01'AND'1995-01-01') 
between 38000 ai 40000) ; 
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图 5-37 不 进行 Multi-Range Read 优 化 的 执行 计划 





可 以 看 到 列 Extra 有 Using index condition 的 提示 。 但 是 为 什么 这 里 的 
idx_s 索 引 会 使 用 Index Condition Pushdown 优 化 呢 ? 因为 这 张 表 的 主键 是 
(emp_no，from_date) 的 联合 索引 ， 所 以 idx_s 索 引 中 包含 了 from_date 的 
数据 ， 故 可 使 用 此 优化 方式 。 


表 5-5 对 比 了 在 MySQL 5.5 和 MySQL 5.6 中 上 述 SQL 语句 的 执行 时 
间 ， 并 且 同 时 比较 开启 MRR 后 的 执行 时 间 。 


$55 MWySQL55 和 NSOQL 56 tre Index Conditon Pushdown 的 执行 时间 | 


EIE 
WS y 
MySQL 6 iC? y 


MySQL 5.6 with ICP & MRR 1810 


上 上 述 的 执行 时 间 的 比较 同样 是 不 对 绥 剖 池 做 任何 的 预 热 操 作 。 可 见 
Index Condition Pushdown 优 化 可 以 将 查询 效率 在 原 有 MySQL 5.5 版 本 的 
技术 上 提高 23%。 而 再 同时 启用 Mulit-Range ”Read 优 化 后 ， 性 能 还 能 有 
400% 的 提升 ! 








5.7 IBS EA 


哈 希 算法 是 一 种 常见 算法 ， 时 间 复 杂 度 为 O (1) ， 且 不 只 存在 于 
索引 中 ， 每 个 数据 库 应 用 中 都 存在 该 数据 库 结 构 。 设 想 一 个 问题 ， 当 前 
服务 器 的 内 存 为 128GB 时 ， 用 户 怎么 从 内 存 中 得 到 某 一 个 被 缓存 的 页 
We? 虽然 内 存 中 查询 速度 很 快 ， 但 是 也 不 可 能 每 次 都 要 过 历 所 有 内 存 来 
21 这 时 对 于 字典 操作 只 需 O (1) 的 哈 希 算 法 就 有 了 很 好 的 用 
武之 地 。 
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哈 希 表 (Hash Table) 也 称 散 列表 ， 由 直接 寻 址 表 改 进而 来 。 我 们 
先 来 看 直接 寻 址 表 。 当 关键 字 的 全 域 U 比 较 小 时 ， 直 接 寻 址 是 一 种 简单 
而 有 效 的 技术 。 假 设 某 应 用 要 用 到 一 个 动态 集合 ， 其 中 每 个 元 素 都 有 一 
个 取 自 全 域 U={0，1，.……，m-lja 的 关键 字 。 同 时 假设 没有 两 个 元 素 具 
有 相同 的 关键 字 。 


用 一 个 数组 ( 即 直接 寻 址 表 〉 T[0..m-1] 表 示 动 态 集合 ， 其 中 每 个 位 
A (或 称 槽 或 桶 〉 对 应 全 域 U 中 的 一 个 关键 字 。 图 5-38 说 明了 这 个 方 
法 ， 槽 k 指 向 集合 中 一 个 关键 字 为 k 的 元 素 。 如 果 该 集合 中 没有 关键 字 为 
k 的 元 素 ， 则 T[k]=NULL。 
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图 5.38 直接 寻 址 表 


直接 寻 址 技术 存在 一 个 很 明显 的 问题 ， 如 果 域 U 很 大 ， 在 一 合 典型 
计算 机 的 可 用 容量 的 限制 下 ， 要 在 机 器 中 存储 大 小 为 U 的 一 张 表 T 就 有 
点 不 实际 ， 甚 至 是 不 可 能 的 。 如 果实 际 要 存储 的 关键 字 集合 K 相 对 于 U 
来 说 很 小 ， 那 么 分 配给 T 的 大 部 分 空间 都 要 浪费 挥 。 


因此 ， 哈 希 表 出 现 了 。 在 哈 希 方式 下 ， 该 元 素 处 于 h Ck) 中， 即 利 
用 哈 希 函数 hn， 根 据 关 键 字 k 计 算出 槽 的 位 置 。 郴 数 h 将 关键 字 域 U 映 射 
到 哈 希 表 IT[0..m-H] 的 槽 位 上 ， 如 图 5-39 所 示 。 














图 5-39 PK 


哈 希 表 技 术 很 好 地 解决 了 直接 寻 址 遇 到 的 问题 ， 但 是 这 样 做 有 一 个 
小 问题 ， 如 图 5-39 所 示 的 两 个 关键 字 可 能 映射 到 同一 个 槽 上 。 一 般 将 这 
种 情况 称 之 为 发 生 了 碰撞 〈collision) 。 在 数据 库 中 一 般 采 用 最 简单 的 
合 撞 解决 技术 ， 这 种 技术 被 称 为 链接 法 〈chaining) 。 

在 链接 法 中 ， 把 散 列 到 同一 槽 中 的 所 有 元 素 都 放 在 一 个 链表 中 ， 如 


图 5-40 所 示 。 权 中 有 一 个 指针 ， 它 指 癌 由 所 有 散 列 到 j 的 元 素 构 成 的 链 
RK: 如果 不 存 在 这 样 的 元 素 ， 则 j 中 为 NULL。 








图 5-40 通过 链表 法 解决 碰撞 的 哈 和 而 表 


最 后 要 考虑 的 是 哈 希 函数 。 哈 布 函 数 h 必 须 可 以 很 好 地 进行 散 列 。 
最 好 的 情况 是 能 避免 碰撞 的 发 生 。 即 使 不 能 避免 ， 也 应 该 使 碰撞 在 最 小 
程度 下 产生 。 一 般 来 次， 都 将 关键 字 转 换 成 自然数， 然后 通过 除法 散 
列 、 乘 法 散 列 或 全 域 散 列 来 实现 。 数 据 库 中 一 般 采 用 除法 散 列 的 方法 。 


在 哈 希 函数 的 除法 散 列 法 中 ， 通 过 取 k 除 以 m 的 余数 ， 将 关键 字 k 映 
SN Elm MB RTS BY is PRB: 





h(k)=k mod m 
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5.7.2 InnoDB 存 储 引 擎 中 的 哈 希 算法 


InnoDB 存 储 引 擎 使 用 哈 希 算法 来 对 字典 进行 查找 ， 其 冲突 机 制 采 
用 链表 方式 ， 哈 希 函 数 采 用 除法 散 列 方式 。 对 于 缓冲 池 页 的 哈 希 表 来 
说 ， 在 绥 冲 池 中 的 Page 页 都 有 一 个 chain 指 针 ， 它 指向 相同 哈 希 函 数值 的 
页 。 而 对 于 除法 散 列 ，m 的 取 值 为 略 大 于 2 倍 的 缓冲 池 页 数量 的 质数 。 
例如 : 当前 参数 innodb_buffer_pool_size 的 大 小 为 10M， 则 共有 640 个 
16KB 的 页 。 对 于 缓冲 池 页 内 存 的 哈 希 表 来 说 ， 需 要 分 配 640x2=1280 个 
槽 ， 但 是 由 于 1280 不 是 质数 ， 需 要 取 比 1280 略 大 的 一 个 质数 ， 应 该 是 
e 所 以 在 启动 时 会 分 配 1399 个 槽 的 哈 希 表 ， 用 来 哈 希 查询 所 在 绥 冲 
池 中 的 页 。 


那么 mnoDB 存 储 引 擎 的 缓冲 池 对 于 其 中 的 页 是 怎么 进行 查找 的 
We? 上 面 只 是 给 出 了 一 般 的 算法 ， 怎 么 将 要 奉 找 的 页 转换 成 目 然 数 呢 ? 


其 实 也 很 简单 ，InnoDB 存 储 引 擎 的 表 空 间 都 有 一 个 space_id， 用 户 
所 要 查询 的 应 该 是 某 个 表 空 间 的 某 个 连续 16KB 的 页 ， 即 偏 移 量 offset。 
InnoDB 存 储 引 擎 将 space_id 左 移 20 位 ， 然 后 加 上 这 个 space_id 和 offset， 
即 关 键 字 K=space_id 二 二 20+space_id+offset， 然 后 通过 除法 散 列 到 各 个 
MPS. 











5.7.3 EDEN S ER SI 


自 适 应 哈 希 索引 采用 之 前 讨论 的 哈 希 表 的 方式 实现 。 不 同 的 是 ， 这 
仅 是 数据 库 自 身 创 建 并 使 用 的 ，DBA 本 身 并 不 能 对 其 进行 干预 。 自 适应 
哈 硕 索引 经 哈 希 函数 映射 到 一 个 哈 希 表 中 ， 因 此 对 于 字典 类 型 的 查找 非 
T DE, 2 TABLE WHERE index_col='xxx'。 但 是 对 于 
范围 查找 就 无 能 为 力 了 。 通 过 命令 SHOW ENGINE INNODB STATUS 可 
以 看 到 当前 目 适 应 哈 希 索引 的 使 用 状况 ， 如 : 











mysql- SHOW ENGINE INNODB STATUS\G; 


ORO ORO ROO KO ROO GO oD CR RR RR Rok e eR Ro e e e ek 


Ibuf: ze 2249,free list len 3346,seg size 5596, 
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Hash able size 4980499, node heap has medi by arte ris ) 
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的 大 小 、 使 用 情况 、 每 秒 使 用 自 适应 哈 希 索引 搜索 的 情况 。 需要 注意 的 
是 ， 哈 希 索 引 只 能 用 来 搜索 等 值 的 得 询 ， 如 ; 








SELECT*FROM table WHERE index col-'xxx' 





而 对 于 其 他 查找 类 型 ， 如 范围 查找 ， EF RR is 2 9| 的 。 因 
此 ， 这 里 出 现 了 non-hash searches/s 的 情况 。 通 过 hash searches:non-hash 
searches 可 以 大 概 了 解 使 用 哈 希 索引 后 o 


HT TEMAER STE 是 由 InnoDB 存 储 引 擎 自己 控制 的 ， 因 此 这 里 
的 这 些 信息 只 供 参 考 。 不 过 可 以 通过 参数 innodb_adaptive_hash_index 来 
禁用 或 启动 此 特性 ， 默 认为 开局 。 


58 ”全文 检索 


5.8.1 概述 
通过 前 面 章 市 的 介绍 ， 已 经 知道 B+ 树 索 引 的 特点 ， 可 以 通过 索引 
FECHA (refi) 进行 得 找 。 例 如 ， 对 于 下 面 的 查询 B+ 树 索引 是 文 


REI: 


SELECT*FROM blog WHERE content like'xxx%' 





上 述 SQL 语 句 可 以 查询 博客 内 容 以 xxx 开 头 的 文章 ， 并 且 只 要 
content 添 加 了 B+ 树 索引 ， 束 能 利用 索引 进行 快速 查询 。 然 而 实际 这 种 碍 
询 不 符合 用 户 的 要 求 ， 因 为 在 更 多 的 情况 下 ， 用 户 需 要 查询 的 是 博客 内 
容 包 含 单词 Xxx 的 文章 ， 即 : 











SELECT*FROM blog WHERE content like'%xxx%' 





根据 B+ 树 索 引 的 特性 ， 上 述 SQL 语 句 即 便 添加 了 B+ 树 索 引 也 是 需 
要 进行 索引 的 扫描 来 得 到 结果 。 类 似 这 样 的 需求 在 互联 网 应 用 中 还 有 很 
多 。 例 如 ， 搜 索引 擎 需要 根据 用 户 和 输入 的 关键 字 进 行 全 文 查 找 ， 电 子 商 
务 网 站 需要 根据 用 户 的 碍 询 条 件 ， 在 可 能 需要 在 商品 的 详细 介绍 中 进行 
查找 ， 这 些 都 不 是 B+ 树 索引 所 能 很 好 地 完成 的 工作 。 


全 文 检索 (Full-Text Search) 是 将 存储 于 数据 库 中 的 整 本 书 或 整 篇 
文章 中 的 任意 内 容 信息 查找 出 来 的 技术 。 它 可 以 根据 需要 获得 全 文中 有 
关 半 、 节 、 上 段 、 句 、 词 等 信息 ， 也 可 以 进行 各 种 统计 和 分 析 。 


在 之 前 的 MySQL 数 据 库 中 ，InnoDB 存 储 引 擎 并 不 支持 全 文 检索 技 
术 。 大 多 数 的 用 户 转 向 MyISAM 存 储 引 擎 ， 这 可 能 需要 进行 表 的 拆 分 ， 
并 将 需要 进行 全 文 检索 的 数据 存储 为 MyISAM 表 。 这 样 的 确 能 够 解决 逻 
辑 业 务 的 需求 ， 但 是 却 丧 失 了 InnoDB 存 储 引 擎 的 事务 性 ， 而 这 在 生产 
环境 应 用 中 同样 是 非常 关键 的 。 


从 InnoDB 1.2.x 版 本 开始 ，InnoDB 存 储 引 擎 开始 支持 全 文 检 索 ， 其 
支持 MyISAM 存 储 引 擎 的 全 部 功能 ， 并 且 还 支持 其 他 的 一 些 特 性 ， 这 些 









































将 在 后 面 的 小 节 中 进行 介绍 。 


5.8.2 ” 倒 排 索引 

全 文 检 索 通 常 使 用 倒 排 索 引 (inverted index) 来 实现 。 倒 排 索引 同 
B+ 树 索引 一 样 ， 也 是 一 种 索引 结构 。 它 在 辅助 表 Cauxiliary table) 中 存 
储 了 单词 与 单词 和 目 身 在 一 个 或 多 个 文档 中 所 在 位 置 之 间 的 映射 。 这 通常 
利用 关联 数组 实现 ， 其 拥有 两 种 表现 形式 : 

Dinverted file index， 其 表现 形式 为 {单词 ， 单 词 所 在 文档 的 ID} 


Dfull invertedindex， 其 表现 形式 为 {单词 ，( 单 词 所 在 文档 的 ID， 在 
具体 文档 中 的 位 置 )} 


例如 ， 对 于 下 面 这 个 例子 ， 表 tt 存储 的 内 容 如 表 5-6 所 示 。 
$6 THRE 


Document Document Ten 
| Some like tt hot, some ike t cold 
) Some like tn the pot 
| Nine days ld 


DocumentId 表 示 进 行 全 文 检索 文档 的 Id，Text 表 示 存 储 的 内 容 ， 用 
户 需 要 对 存储 的 这 些 文 档 内 容 进 行 全 文 检 索 。 例 如 ， 碍 找 出 现 过 Some 
中 词 的 文档 1， 又 或 者 查找 单个 文档 中 出 现 过 两 个 Some 单 词 的 文档 Id， 

















对 于 inverted file index 的 关联 数组 ， 其 存储 的 内 容 如 表 5-7 所 示 。 


851 inverted fle index RR 


Number | — Text Documents | Number Text Documents 








可 以 看 到 单词 code 存 在 于 文档 1 和 4 中 ， 单 词 days 存 在 与 文档 3 和 6 
中 。 之 后 再 要 进行 全 文 得 询 就 简单 了 ， 可 以 直接 根据 Documents 得 到 包 
含 查 询 关 键 字 的 文档 。 对 于 inverted file index， 其 仅 存 取 文 档 Id， 而 full 
inverted index 存 储 的 是 对 (pair)， 即 (DocumentId，Position)， 因 此 其 存储 
的 倒 排 索引 如 表 5-8 所 示 。 
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full inverted index 还 存储 了 单词 所 在 的 位 置信 息 ， 如 code 这 个 单词 
出 现在 (126) ， 即 文档 1 的 第 6 个 单词 为 code。 相 比 之 下 ，full inverted 
index 占 用 更 多 的 空间 ， 但 是 能 更 好 地 定位 数据 ， 并 扩充 一 些 其 他 的 搜 


索 特性 。 


5.8.3 ”InnoDB 全 文 检索 


InnoDB 存 储 引 擎 从 1.2.x 厂 本 开始 文 持 全 文 检索 的 技术 ， 其 采用 full 
inverted index 的 方式 。 在 InnoDB 存 储 引 擎 中 ， 将 (DocumentId，Position) 
视 为 一 个 “ilist*。 因 此 在 全 文 检索 的 表 中 ， 有 两 个 列 ， 一 个 是 word 字 
段 ， 男 一 个 是 ilist 字 段 ， 并 且 在 word 字 段 上 有 设 有 索引 。 此 外 ， 由 于 
InnoDB 存 储 引 擎 在 ilist 字 段 中 存放 了 Position 信 息 ， 故 可 以 进行 Proximity 
Search， 而 MyISAM 存 储 引 擎 不 文 持 该 特性 。 


正如 之 前 所 说 的 那样 ， 倒 排 索 引 需 要 将 word 存 放 到 一 张 表 中 ， 这 个 
表 称 为 Auxiliary Table〈 辅 助 表 ) 。 在 InnoDB 存 储 引 擎 中 ， 为 了 提高 
文 检 索 的 并 行 性 能 ， 共 有 6 张 Auxiliary ”Table， 目 前 每 张 表 根 据 word 的 
Latin 编 码 进行 分 区 。 


Auxiliary Table 是 持久 的 表 ， 存 放 于 磁盘 上 。 然 而 在 InnoDB 存 储 引 
擎 的 全 文 索引 中 ， 还 有 夯 外 一 个 重要 的 概念 FTS Index Cache (全 文 检索 
索引 缓存) ， 其 用 来 提高 全 文 检 索 的 性 能 。 


FTS Index Cache 是 一 个 红 黑 树 结 构 ， 其 根据 〈word，ilist) 进行 排 
序 。 这 意味 着 插入 的 数据 已 经 更 新 了 对 应 的 表 ， 但 是 对 全 文 罕 引 的 更 新 
可 能 在 分 词 操 作 后 还 在 FTS Index Cache 中 ，Auxiliary Table 可 能 还 没有 
更 新 。InnoDB 存 储 引 擎 会 批量 对 Auxiliary Table 进 行 更 新 ， 而 不 是 每 次 
插入 后 更 新 一 次 Auxiliary Table。 当 对 全 文 检索 进行 查询 时 ，Auxiliary 
Table 首 先 会 将 在 FTS Index Cache 中 对 应 的 word 字 上 段 合 并 到 Auxiliary 
Table 中 ， 然 后 再 进行 查询 。 这 种 merge 操 作 非 常 类 似 之 前 介绍 的 Insert 
Buffer 的 功能 ， 不 同 的 是 Insert Buffer 是 一 个 持久 的 对 象 ， 并 且 其 是 B+ 树 
的 结构 。 然 而 FTS Index Cache 的 作用 又 和 Insert Buffer 是 类 似 的 ， 它 提高 
了 InnoDB 存 储 引 擎 的 性 能 ， 并 且 由 于 其 根据 红 黑 树 排 序 后 进行 批量 插 
入 ， 其 产生 的 Auxiliary Table 相 对 较 小 。 


InnoDB 存 储 引 苟 允 许 用 户 查 看 指定 倒 排 索引 的 Auxiliary Table 中 分 
词 的 信息 ， 可 以 通过 设置 参数 innodb_ft_aux_table 来 观察 倒 排 索引 的 
Auxiliary Table。 下 面 的 SQL 语句 设置 得 看 test 架 构 下 表 fts_a 的 Auxiliary 
Table: 



































mysql>SET GLOBAL innodb ft aux table-'test/fts a'; 
Query OK,0 rows affected(0.00 sec) 





在 上 述 设置 完成 后 ， 就 可 以 通过 查询 information_schema 架 构 下 的 
表 INNODB FT _INDEX_TABLE 得 到 表 fts_a 中 的 分 词 信息 。 


对 于 其 他 数据 库 ， 如 Oracle 11g， 用 户 可 以 选择 手工 在 事务 提交 
时 ， 或 者 固定 间隔 时 间 时 将 倒 排 索引 的 更 新 刷新 到 人 破 盘 。 对 于 InnoDB 
存储 引擎 而 言 ， 其 总 是 在 事务 提交 时 将 分 词 写 入 到 FTS Index Cache， 然 
后 再 通过 批量 更 新 写 入 到 磁盘 。 虽 然 imnoDB 存 储 引 擎 通过 一 种 延 时 
式 来 提高 数据 库 的 性 能 ， 但 是 上 述 操作 仅 在 事务 提交 
时 发 生 。 


当 数 据 库 关闭 时 ， 在 FTS Index Cache 中 的 数据 库 会 同步 到 磁盘 上 的 
Auxiliary Table 中 。 然 而， 如 果 当 数据 库 发 生 宕 机 时 ， 一 些 FTS Index 
Cache 中 的 数据 库 可 能 未 被 同步 到 磁盘 上 。 那 么 下 次 重 局 数据 库 时 ， 妆 
用 户 对 表 进 行 全 文 检索 (查询 或 者 插入 操作 〉 时 ，InnoDB 存 储 引 擎 会 
目 动 读 取 未 完成 的 文档 ， 然 后 进行 分 词 操 作 ， 再 将 分 词 的 结果 放 入 到 
FTS Index Cache 中 。 























参数 innodb_ft_cache_size 用 来 控制 FTS Index Cache 的 大 小 ， 默 认 值 
为 32M。 当 该 缓存 满 时 ， 会 将 其 中 的 (word，ilist) 分 词 信息 同步 到 磁盘 的 
Auxiliary ”Table 中 。 增 大 该 参数 可 以 提高 全 文 检 索 的 性 能 ， 但 是 在 宕 机 
时 ， 未 同步 到 磁盘 中 的 索引 信息 可 能 需要 更 长 的 时 间 进 行 恢复 。 


FTS Document ID 是 另外 一 个 重要 的 概念 。 在 InnoDB 存 储 引 擎 中 ， 
为 了 文 持 全 文 检索 ， 必 须 有 一 个 列 与 word 进 行 映 射 ， 在 ImnoDB 中 这 个 
列 被 命名 为 FTS_DOC_ID， 其 类 型 必须 是 BIGINT UNSIGNED NOT 
NULL， 并 且 InnoDB 存 储 引 擎 自动 会 在 该 列 上 加 入 一 个 名 为 
FTS DOC ID INDEX 的 Unique Index。 上 述 这 些 操作 都 由 InnoDB 存 储 引 
擎 自己 完成 ， 用 户 也 可 以 在 建 表 时 目 动 添加 FTS_DOC_ID， 以 及 相应 的 
Unique “ Index。 由 于 列 名 为 FTS_DOC_ID 的 列 具有 特殊 意义 ， 因 此 创建 
时 必须 注意 相应 的 类 型 ， 和 否则 MySQL 数 据 库 会 抛 出 错误 ， 如 ; 











mysql>CREATE TABLE fts a( 
-2FTS DOC ID INT UNSIGNED AUTO INCREMENT NOT NULL, 


>body TEXT, 
->PRIMARY KEY(FTS DOC ID) 


->); 
ERROR 1166(42000):Incorrect column name'FTS_DOC_ID' 





可 以 看 到 ， 由 于 用 户 手动 定义 的 列 FTS_DOC_ID 的 类 型 是 INT， 而 
非 BIG INT， 因 此 在 创建 的 时 候 抛 出 了 Incorrect column 


nameFTS_DOC_ID'， 因 此 需 将 该 列 修改 为 对 应 的 数据 类 型 ， 如 : 





mysql>CREATE TABLE fts a( 
-—FTS DOC ID BIGINT UNSTGNED AUTO_INCREMENT NOT NULL, 
->body TEXT, 

RMARY KEY(FTS_DOC_ID) 


0 uer ry OK,0 rows affected(0.02 sec) 





文档 中 分 词 的 插入 操作 是 在 事务 提交 时 完成 ， 然 而 对 于 删除 操作 ， 
其 在 事务 提交 时 ， 不 删除 磁盘 Auxiliary Table 中 的 记录 ， 而 只 是 删除 FTS 
Cache Index 中 的 记录 。 对 于 Auxiliary Table 中 被 删除 的 记录 ，InnoDB 存 
储 引 擎 会 记录 其 FTS Document ID， 并 将 其 保存 在 DELETED auxiliary 
table 中 。 在 设置 参数 innodb_ ft_aux_table 后 ， 用 户 同 样 可 以 访问 
information_schema 架 构 下 的 表 INNODB FT DELETEPD 来 观察 删除 的 
FTS Document ID. 


由 于 文档 的 DML 操 作 实 际 并 不 删除 索引 中 的 数据 ， 相 反 还 会 在 对 
应 的 DELETED 表 中 插入 记录 ， 因 此 随 着 应 用 程序 的 允许 ， 索 引 会 变 得 
非常 大 ， 即 使 索引 中 的 有 些 数 据 已 经 被 删除 ， 查 询 也 不 会 选择 这 类 记 
录 。 为 此 ，InnoDB 存 储 引 擎 提供 了 一 种 方式 ， 允 许 用 户 手工 地 将 已 经 
删除 的 记录 从 索引 中 彻底 删除 ， 该 命令 就 是 OPTIMIZE TABLE. XX 
OPTIMIZE “TABLE 还 会 进行 一 些 其 他 的 操作 ， 如 Cardinality 的 重新 统 
计 ， 若 用 户 希 望 仅 对 倒 排 索引 进行 操作 ， 那 么 可 以 通过 参数 
innodb_optimize_fulltext_only 进 行 设 置 ， 如 : 








mysql>SET GLOBAL innodb optimize fulltext only-1; 
mysql>OPTIMIZE TABLEfts a; 





若 被 删除 的 文档 非常 多 ， 那 么 OPTIMIZE TABLE 操 作 可 能 需要 占用 
非常 多 的 时 间 ， 这 会 影响 应 用 程序 的 并 发 性 ， 并 极 大 地 降低 用 户 的 响应 
时 间 。 用 户 可 以 通过 参数 innodb_ft_num_word_optimize 来 限制 每 次 实际 
删除 的 分 词 数 量 。 访 参数 的 默认 值 为 2000。 


下 面 来 看 一 个 具体 的 例子 ， 首 先 通 过 如 下 代码 创建 表 fts_a: 





CREATE TABLE fts a( 
FTS DOC ID BIGINT UNSIGNED AUTO INCREMENT NOT NULL, 


ody TEXT, 
PRIMARY KEY(FTS. DOC. ID) 


i 

INSERT INTO fts_a 

SELECT NULL, 'Pease porridge in the pot'; 
a 


SELECT NULL, 'Pease porridge hot,pease porridge cold'; 
INSERT INTO fts_a 
SELECT NULL, 'Nine days old'; 


INSERT INTO fts a 

SELECT NULL,'Some like it hot,some like it cold'; 
INSERT INTO fts a 

SELECT NULL,'Some like it in the pot'; 

INSERT INTO fts a 

SELECT NULL, 'Nine days old'; 

INSERT INTO fts a 

SELECT NULL,'I like code days'; 

CREATE FULLTEXT INDEX idx fts ON fts a(body); 





上 述 代 码 创 建 了 表 fts_a， 由 于 body 字 段 是 进行 全 文 检索 的 字段 ， 因 
此 | 28707 索引 。 这 里 首先 导入 数据 ， 然 后 再 进行 
倒 排 索引 的 创建 ， 这 也 是 比较 推荐 的 一 种 方式 。 创 建 完成 后 观察 到 表 
fts_a 中 的 数据 : 























Welter “FROM fts a; 


| ase puru in the pot| 

|2|Pease porridge hot,pease porridge cold| 
|3|Nine days old| 

|4|Some like it hot,some like it cold| 
|5|Some like it in the pot| 

|6|Nine days old| 

|7|I like coge days| 


7 rows in Soto de sec) 





通过 设置 参数 innodb ft aux _table 来 查看 分 词 对 应 的 信息 : 





mysql>SET GLOBAL innodb ft aux table-'test/fts a'; 

Query OK,0 rows affected(0.00 sec) 

mysql >SELECT” FROM arene schema.INNODB FT INDEX TABLE; 
----------+--------------+------------- +-----------+--------+----------+ 
WORD FIRST DOC ID|LAST | boc . ID|DOC ! COUNT IROG ZB POSTTZONI 














|porridge|1|2 
|porridge|1|2 
|pot|1|5|2|1|22 
|pot|1|5|2|5|20 
|[some|4|5|2|4|0 
|some|4|5|2|4[|18| 
[some|4|5|2|5]|0 
+---------- +-------------- +------------- +----------- +-------- +---------- 十 
27 rows in set(0.00 sec) 











可 以 看 到 每 个 word 都 对 应 了 一 个 DOC_ID 和 POSITION。 此 外 ， 还 
记录 了 FIRST_DOC_ ID、LAST_DOC_ID 以 及 DOC_COUNT， 分 别 代 表 


了 该 word 第 一 次 出 现 的 文档 ID， 最 后 一 次 出 现 的 文档 ID， 以 及 该 word 
在 多 少 个 文档 中 存在 。 


知 这 时 执行 下 面 的 SQL 语句 ， 会 删除 FTS_DOC _ID 为 7 的 文档 : 





mysql>DELETE FROM test.fts a WHERE FTS DOC ID-7; 
Query OK,1 row affected(0.00 sec) 





由 于 之 前 的 介绍 ，InnoDB 存 储 引擎 并 不 会 直接 删除 索引 中 对 应 的 
C a rece ae 因此 用 户 可 以 进行 如 
下 的 查询 : 








mysql>SELECT*FROM INNODB FT DELETED; 
+ 


i row in Cort 00 sec) 





可 以 看 到 删除 的 文档 iD 插入 到 了 表 INNODB_ FT_DELETED 中 ， 若 
用 户 想 R 分 词 信息 ， 那 么 可 以 运行 如 下 的 
SQL 语 








mysql>SET GLOBAL innodb optimize fulltext only-1; 
Query OK,0 rows affected(0.00 sec) 
mysqi> OPTIMIZE TABLE teet fts a; 


+------------+----------+----------+----------+ 
+------------+----------+----------+----------+ 


+------------+----------+----------+----------+ 
1 row in RA 01 sec) 

IgE SELECT" FROM INNODB FT DELETED; 

i 


和 

+--------+ 

1 row in set(0.00 sec) 

mysql>SELECT* ERO INNODB FT BEING DELETED; 
fae see as 


ELETE E E 


rO ENE TE 
1 row in SEC: 00 sec) 





通过 上 面 的 例子 可 以 看 到 ， 运 行 命令 OPTIMIZE TABLE 可 将 记录 进 
行 彻 底 的 删除 ， 并 且 和 彻底 删除 的 文档 ID 会 记录 到 表 
INNODB_FT_BEING_DELETED 中 。 此 外 ， 由 于 7 这 个 文档 ID 已 经 被 删 
除 ， 因 此 不 允许 再 次 插入 这 个 文档 ID， 和 否则 数据 库 会 抛 出 如 下 异常 





mysql>INSERT INTO test.fts a SELECT 7,'I like this days'; 
ERROR 182(HY000):Invalid InnoDB FTS Doc ID 





stopword 列 表 (stopword list) 是 本 小 节 最 后 阐述 的 一 个 概念 ， 其 表 
示 该 列表 中 的 word 不 需要 对 其 进行 索引 分 词 操作 。 例 如 ， 对 于 the 这 个 
单词 ， 由 于 其 不 具有 具体 的 意义 ， 因 此 将 其 视 为 stopword。InnoDB 存 储 
引擎 有 一 张 默认 的 stopword 列 表 ， 其 在 information_schema 架 构 下 ， 表 名 
为 INNODB_FT_DEFAULT_STOPWORD， 默 认 共 有 36 个 stopword。 此 
外 用 户 也 可 以 通过 参数 innodb_ft_server_stopword_table 来 自 定 义 
stopword 列 表 。 如 : 








mysql>CREATE TABLE user stopword( 

->value VARCHAR(30) 

-> JENGINE-INNODB; 

Quer ,0 rows affected(0.03 sec) 

mysql>SET GLOBAL 
->innodb_ft_server_stopword_table="test/user_stopword"; 
Query OK,0 rows affected(0.00 sec) 





当前 InnoDB 存 储 引 擎 的 全 文 检 索 还 存在 以 下 的 限制 : 
口 每 张 表 只 能 有 一 个 全 文 检 索 的 索引 。 


口 由 多 列 组 合 而 成 的 全 文 检 索 的 索引 列 必须 使 用 相同 的 字符 集 与 排 
序 规则 。 


口 不 支持 没有 单词 界定 符 (delimiter〉 的 语言 ， 如 中 文 、 Ais. Rp 
AE 


ta wT 





5.8.4 ”全 文 检索 
MySQL 数 据 库 支持 全 文 检索 (Full-Text Search) 的 查询 ， 其 语法 





MATCH(coli, bend . )JAGAINST(expr [search modifier]) 
search modifie 


1 

IN NATURAL LANGUAGE MODE 

|IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION 
|IN BOOLEAN MODE 

|WITH QUERY EXPANSION 

} 





MySQL 数 据 库 通 过 MATCH(...AGAINSTO 语 法 支持 全 文 检索 的 查 
询 ，MATCH 指 定 了 需要 被 查询 的 列 ，AGAINST 指 定 了 使 用 何 种 方法 去 
进行 查询 。 下 面 将 对 各 种 查询 模式 进行 详细 的 介绍 。 


1.Natural Language 


全 文 检索 通过 MATCH 消 数 进行 查询 ， 默 认 采 用 Natural Language 模 
式 ， 其 表示 但 询 帝 有 指定 word 的 文档 。 对 于 5.8.3 小 市 中 创建 的 表 fts_a， 
查询 body 字 段 中 带 有 Pease 的 文档 ， 夺 不 使 用 全 文 索 引 技术 ， 则 允许 使 
用 下 述 SQL 语 句 : 











mysql>SELECT*FROM fts a WHERE body LIKE'%Pease%'; 












































显然 上 述 SQL 语 所 略 采 用 全 文 检索 技术 ， 可 以 


用 下 面 的 SQL 语句 进行 查询 : 


M 
PRI 





mysql>SELECT*FROM fts a 
->WHERE MATCH(body) 
2>AGAINST(! Porridge’ IN NATURAL LANGUAGE MODE); 


Je ae por id hot, pease porridge cold| 
[alvease porridge in the pot | 


H rows in eee 00 sec) 





由 于 NATURAL LANGUAGE MODE 是 默认 的 全 文 检索 查询 模式 ， 
因此 用 户 可 以 省 略 查 询 修 饰 人 符 ， 即 上 述 SQL 语 句 可 以 写 为 : 





SELECT*FROM fts a WHERE MATCH(body)AGAINST('Porridge'); 


观察 上 述 SQL 语 句 的 查询 计划 ， 可 得 : 





mysql>EXPLAIN SELECT*FROM fts. 
->WHERE MATCH(bo dy JAGATNST( ' is rridge')\G; 


JOOOOOOOOOOOOOOOO EROR GOOOOOOR] POF ICICI ICICI ICICI III IIIA II IE 
id:1 

vedi edu SIMPLE 

table 


AUR Hi Ies t 
ible keys: idx_fts 
idx_ft 


Extra:Using wher 
1 RA in xo Ee sec) 





可 以 看 到 ， 在 type 这 列 显示 了 falltext， 即 表示 使 用 全 文 检索 的 倒 排 
索引 ， 而 key 这 列 显示 了 idx_fts， 表 示 索 引 的 名 字 。 可 见 上 述 查 询 使 用 
了 全 文 检索 技术 。 同 时 ， 若 表 没 有 创建 倒 排 索引 ， 则 执行 MATCH 函 数 
会 抛 出 类 似 如 下 错误 : 








mysql-SELECT*FROM fts b 
- >WHERE METER LIBRA CARNETS Porridge'); 
ERROR 1191(HY000):Can't find FULLTEXT index matching the column list 





在 WHERE 条 件 中 使 用 MATCH 函 数 ， 查 询 返 回 的 结果 是 根据 相关 性 
(Relevance) 进行 降序 排序 的 ， 即 相关 性 最 高 的 结果 放 在 第 一 位 。 相 关 
性 的 值 是 一 个 非 负 的 浮 点 数字 ，0 表 示 没 有 任何 的 相关 性 。 根 据 MySQL 
官方 的 文档 可 知 ， 其 相关 性 的 计算 依据 以 下 四 个 条 件 : 


Dword 是 否 在 文档 中 出 现 。 
Dword 在 文档 中 出 现 的 次 数 。 
口 word 在 索引 列 中 的 数量 。 
口 多 少 个 文档 包含 该 word。 


对 于 上 述 碍 询 ， 由 于 Porridge 在 文档 2 中 出 现 了 两 次 ， 因 而 具有 更 高 
的 相关 性 ， 故 第 一 个 显示 。 


为 了 统计 MATCH 函 数 得 到 的 结果 数量 ， 可 以 使 用 下 列 SQL 语 句 : 














mys ql >SELECT cou ne ) 
ROM fts a WHE! 
S CMATEH Bod JAEK RET Porridge'IN NATURAL LANGUAGE MODE); 


1 row in set(0.00 oH 





上 述 SQL 语 名 也 可 以 重 写 为 ; 





mysql-—SELECT 

- 2 COUNT ( IF(MATCH(body) 

-—AGAINST('Porridge'IN NATURAL LANGUAGE MODE),i1,NULL)) 
->AS count 

- >FROM T a; 


1 row in set(0.00 sec) 





Ea FY AJ SQL ERE 吉 果 是 相同 的 ， 但 是 从 内 部 运行 
来 看 ， 第 二 句 SQL 的 执行 速度 可 能 更 快 些 。 这 是 因为 第 一 句 SQL 语 句 还 
需要 进行 相关 性 的 排序 统计 ， 而 在 第 二 句 SQL 中 是 不 ` 需 要 的 。 


此 外 ， 用 户 可 以 通过 SQL 语 句 伍 看 相关 性 








mysql>SELECT fts_doc_id, body, 
- MATCH(body )AGAINST ( ' Porridge' IN NATURAL LANGUAGE MODE) 
->AS Relevance 
FERON fts -ai 
------------+----------------------------------------- +--------------------+ 
Its doc “di body [Relevance] 
------------+----------------------------------------- +--------------------+ 
| 了 DCUM in the pot|0.2960100471973419| 
|2|Pease porridge hot,pease porridge cold|0.5920200943946838 | 
|3|Nine days old|0| 
|4|Some like it hot,some like it cold|0| 
|5|Some like it in the pot|0| 
|6|Nine days old|0| 
els like hot Ads code days|0| 
------------+----------------------------------------- +--------------------+ 
: rows in Cette. 01 sec) 





对 于 InnoDB 存 储 引 擎 的 全 文 检索 ， 还 需要 考虑 以 下 的 因素 : 
口 查 询 的 word 在 stopword 列 中 ， 忽 略 该 字符 串 的 查询 。 


口 查 询 的 word 的 字符 长 度 是 否 在 区 间 [innodb ft min. token. size; 
innodb ft max token. size]. 


如 果 词 在 stopword 中 ， 则 不 对 该 词 进行 查询 ， 如 对 the 这 个 词 进行 奉 
询 ， 结 果 如 下 所 示 : 








mysql>SELECT fts doc id AS id,body, 
-—MATCH(body)AGAINST('the'IN NATURAL LANGUAGE MODE) 


->FROM fts a; 
+----+----------------------------------------- +------ 十 
|id|body|r1| 
+----+----------------------------------------- +------ 十 
|1|Pease porridge in the pot|0| 

|2|Pease porridge hot,pease porridge cold|0| 

|3|Nine days old|0| 

|4|Some like it hot,some like it cold|0| 

|5|Some like it in the pot|0| 

|6|Nine days old|0| 

|7|I like hot and code days|0| 

+---- +-----------------------------------------+------+ 
7 rows in set(0.00 sec) 


0 
+ 








可 以 看 到 ，the 虽 然 在 文档 1、5 中 出 现 ， 但 由 于 其 是 stopword， 故 其 
相关 性 为 0。 


参数 innodb ft min token_size 和 innodb ft max token_size 控 制 
InnoDB 存 储 引擎 查询 字符 的 长 度 ， 当 长 度 小 于 
innodb_ft_min_token_size， 或 者 长 度 大 于 innodb_ft_max_token_size 时 ， 
会 忽略 该 词 的 搜索 。 在 InnoDB 存 储 引 擎 中 ， 参 数 
innodb_ft_min_token_size 的 默认 值 为 3， 参 数 innodb_ft_max_token_size 的 
默认 值 为 84。 





2.Boolean 


MySQL 数 据 库 允 许 使 用 IN BOOLEAN MODE 修 饰 符 来 进行 全 文 检 
索 。 当 使 用 该 修饰 符 时 ， 查 询 字 符 串 的 前 后 字符 会 有 特殊 的 含义 ， 例 如 
下 面 的 语句 要 求 查 询 有 字符 串 Pease 但 没有 hot 的 文档 ， 其 中 + 和 -分 别 表 
示 这 个 单词 必须 出 现 ， 或 者 一 定 不 存在 。 








Kk IR RIK IK IK IK IO ko koe de ke ke 4 pg ROCK koe ok ko koe ke ee ke eek ke ee 


FTS DOC ID:1 
body:Pease porridge in the pot 





Boolean 全 文 检索 支持 以 下 几 种 操作 符 : 
口 + 表示 该 word 必 须 存 在 。 
口 -表示 该 word 必 须 被 排除 。 


口 (no operator) 表示 该 word 是 可 选 的 ， 但 是 如 果 出 现 ， 其 相关 性 
会 更 高 


DQ@distance 表 示人 查询 的 多 个 单词 之 间 的 距离 是 否 在 distance 之 内 ， 
distance 的 单位 是 字 节 。 这 种 全 文 检索 的 查询 也 称 为 Proximity Search. 

















如 MATCH (body) AGAINST ("Pease pot"@30'IN BOOLEAN MODE) 
表示 字符 串 Pease 和 pot 之 间 的 距离 需 在 30 字 节 内 。 


口 二 表示 出 现 该 单词 时 增加 相关 性 
口 二 表示 出 现 该 单词 时 降低 相关 性 


口 一 表示 允许 出 现 该 单词 ， 但 是 出 现时 相关 性 为 负 《 全 文 检 索 碍 询 
多 许 负 相关 性 ) 。 


口 * 表 示 以 该 单词 开头 的 单词 ， 如 lik*， 表 示 可 以 是 lik、1like， 又 或 
likes. 


口 "表示 短语 。 


接着 将 根据 上 述 的 操作 符 及 之 前 创建 的 表 fts_a 来 进行 具体 的 介绍 。 
下 面 的 SQL 语句 返回 有 pease 又 有 hot 的 文档 : 

















mysql>SELECT*FROM fts a 

- WHERE AAA RENE *Pease-hot'IN BOOLEAN MODE)\G; 
KKKERRKKKKEERKKKKEERKKKKERRJ | p CROOOROOROOOOOROOIOOOOIOROROOIOOOEOER 
FTS DOC ID:2 
body:Pease porridge hot,pease porridge cold 
1 row in set(0.00 sec) 





下 面 的 SQL 语句 返回 有 pease 但 没有 hot 的 文档 : 





mysql>SELECT*FROM fts a 

- WHERE Sla esc pss E paeem hot'IN BOOLEAN MODE)\G; 
FOI III III ISI IIIS on QI IOI III III III III IO IG I ok 
FTS_DOC_ID:1 
body:Pease porridge in the pot 
1 row in set(0.00 sec) 





下 面 的 SQL 语句 返回 有 pease 或 有 hot 的 文档 : 





mysql-SELECT*FROM fts a 
Princi MATCH (body )AGATNST (* Pease hot'IN BOOLEAN MODE); 


dal Puase nórridge hot,pease porridge cold| 
|1i|Pease porridge in the pot | 

|4|Some like it hot,some like it cold| 
Ten like hot and code days| 


4 rows in set(0.00 sec) 





下 面 的 SQL 语句 进行 Proximity Search: 


De st 


mysql>SELECT fts_doc_id,body FROM fts_a 

->WHERE MATCH(body) 

->AGAINST('"Pease pot"@30'IN BOOLEAN MODE)\G; 
m""-———— 

fts doc id:1 

body:Pease porridge in the pot 

1 row in set(0.01 sec) 

mysql>SELECT fts doc id,body FROM fts a 

->WHERE MATCH(body) 

-—AGAINST('"Pease pot"Q10'IN BOOLEAN MODE); 

Empty set(0.01 sec) 








Be pace pay ae 因此 第 一 条 @30 
的 查询 可 以 返回 结果 ， 而 之 后 @10 的 条 件 不 能 返回 任何 结果 。 如 : 





mysql>SELECT fts_doc_id, body, 
->MATCH(body)AGAINST('like>pot'IN BOOLEAN MODE) 
Pla Voas FROM fts a; 
------------+----------------------------------------- +---------------------+ 


ifs. doc. Lid] body [Relevance] 
------------+----------------------------------------- +---------------------+ 
ede porridge in the pot|1.2960100173950195| 

|2|Pease porridge hot,pease porridge cold|0| 

|3|Nine days old|0| 

|4|Some like it hot,some like it cold|0.27081382274627686| 

|5|Some like it in the pot|1.4314169883728027 | 

|6|Nine days old|0| 

diz like hot and code days|0.13540691137313843| 
------------+----------------------------------------- +---------------------+ 


rows in setlo. 00 sec) 





上 述 SQL 语 句 查询 根据 是 否 有 单词 like 或 pot 进 行 相关 性 统计 ， 并 且 
出 现 单 词 pot 后 相关 性 需要 增加 。 文 档 4 虽 然 出 现 两 个 like 单 词 ， 但 是 没 
有 pot， 因 此 相关 性 没有 文档 1 和 5 高 。 


下 面 的 查询 增加 了 “二 some” 的 条 件 ， 最 后 得 到 的 结 











mysql>SELECT fts_doc_id, body, 
-—MATCH(body)AGAINST('like-hot-some'IN BOOLEAN MODE) 

->AS Relevance 

SEREM fts ee 

------------+----------------------------------------- +---------------------+ 


Ift doc “di body [Relevance] 
------------+----------------------------------------- +---------------------+ 
idies ord in the pot|0| 

|2|Pease porridge hot,pease porridge cold|1.2960100173950195| 

|3|Nine days old|0| 

|4|Some like it hot,some like it cold|1.158843994140625| 

|5|Some like it in the pot|-0.5685830116271973| 

|6|Nine days old|0| 

diz like hot ahd code days|0.13540691137313843| 
------------+----------------------------------------- +---------------------+ 


rows in setlo, 00 sec) 





可 以 发 现 文档 5 的 相关 性 变 为 了 负 ， 这 是 因为 虽然 其 中 存在 like 单 
但 是 也 存在 some 单 词 ， 所 以 根据 但 询 条 件 ， 其 相关 性 变 为 了 负 相 


接 独 来 看 下 面 的 SQL 语句 : 





mysql>SELECT*FROM fts a 
E MATCH(body)AGAINST('po*'IN BOOLEAN MODE); 


ace de hot, pease porridge cold| 

|1|Pease porridge in the pot | 

[Biseme like It in the pot| 

S T EEN EA N E ee 


M rows in Sotto. 00 sec) 








可 以 看 到 最 后 结果 中 的 文档 包含 以 po 开头 的 单词 ， 如 porridge， 
pot。 





最 后 是 关于 短语 的 SQL 查询 ， 如 : 





mysql-SELECT*FROM fts 
oe HATCH (body AGAENST(' like hot'IN BOOLEAN MODE); 


qd sone like it hot,some like it cold| 
|7|I like hot and code days| 

|2|Pease porridge hot, Re porridge cold| 
[lees like It in the pot| 


A rows in pe 00 sec) 
mysql>SELECT*FROM fts a 
->WHERE MATCH(body)AGAINST('"like hot"'IN BOOLEAN MODE); 


+------------+---------------------------+ 
+------------+---------------------------+ 


eet eee ee 


1 row in ue 00 sec) 





可 以 看 到 第 一 条 SQL 语句 没有 使 用 "… 将 like 和 hot 视 为 一 个 短语 ， 而 
只 是 将 其 视 为 两 个 单词 ， 因 此 结果 共 返 回 4 个 文档 。 nc im 
使 用 "like hot"， 因 此 碍 询 的 是 短语 ， 故 仅 文 档 4 符 合 查 询 条 件 。 





3.Query Expansion 


MySQL 数 据 库 还 文 持 全 文 检 索 的 扩展 得 询 。 这 种 但 询 通 单 在 得 询 
的 关键 词 太 短 ， 用 户 需要 implied ”knowledge〔( 隐 含 知识 ) 时 进行 。 例 
如 ， 对 于 单词 database 的 查询 ， 用 户 可 能 希望 查询 的 不 仅仅 是 包含 
database 的 文档 ， 可 能 还 指 那些 包含 MySQL、Oracle、DB2、RDBMS 的 
单词 。 而 这 时 可 以 使 用 Query Expansion 模式 来 开启 全 文 检索 的 implied 
knowledge. 








通过 在 查询 短语 中 添加 WITH QUERY EXPANSION 或 IN 
NATURAL LANGUAGE MODE WITH QUERY EXPANSION 可 以 开启 


blind query expansion 〈 又 称 为 automatic relevance feedback) 。 该 查询 分 
为 两 个 阶段 。 





一 阶段 : 根据 搜索 的 单词 进行 全 文 索 引得 询 。 


is 口 第 二 阶段 : 根据 第 一 阶段 产生 的 分 词 再 进行 一 次 全 文 检 索 的 碍 
TH] o 





接着 来 看 一 个 具体 的 例子 ， 首 先 根据 如 下 代码 创建 测试 表 articles: 





CREATE TABLE articles( 
id INT UNSIGNED AUTO INCREMENT NOT NULL PRIMARY KEY, 
title VARCHAR(200), 
body TEXT, 
FULLTEXT(title, body) 
-InnoDB; 

ENGINE-I DB 
INSERT INTO articles(title,body)VALUES 

('MySQL Tutorial','DBMS stands for DataBase...'), 

('How To Use MySQL Well','After you went through a...'), 
('Optimizing MySQL','In this tutorial we will show...'), 
('1001 MySQL Tricks','1.Never run mysqld as root.2....'), 
('MySQL vs.YourSQL','In the following database comparison...'), 
('MySQL Security','When configured properly,MySQL...'), 
('Tuning DB2','For IBM database...'), 

('IBM History', 'DB2 hitory for IBM...'); 





在 这 个 例子 中 ， 并 没有 显示 创建 FTS_ DOC ID 列 ， 因 此 InnoDB 存 储 
5 索引 。 此 外 ， 表 articles 的 全 文 检 索索 
。 接 着 根据 database 关 键 字 进 行 的 全 文 











` 
v 
dw 





引擎 会 
引 是 根据 列 tite 和 body 的 联合 
检索 查询 。 











mysql>SELECT*FROM articles 
->WHERE MATCH(title, body) 
AS database'IN NATURAE LANGUAGE MODE); 


ANO SK IUD he MET NM QNT Sr MEE RE 十 
[id] titie body 

c sodososesccoeqldecreecebesteceenjesscqeenedómueengsmecomeguum be dgd 十 
M eee Tutorial|DBMS abdi for DataBase. 

[5|MySQL vs.YourSQL|In the Moser database comparison...| 
eng DB2|For IBM Ek Re | 
人 十 


rows in set(0.00 sec) 








可 以 看 到 ， 查 询 返 回 了 3 条 记录 ， body 字 段 包 含 database 关 键 字 。 接 
着 开启 Query Expansion， 观 察 最 后 得 到 的 结果 如 下 所 示 : 





mysql>SELECT*FROM articles 
->WHERE MATCH(title, body) 
rites aces database 'WITH UE EXPANSION); 


十 
iaititielpoty 
----+----------------------- +------------------------------------------+ 
CE vs.YourSQL|In the following database comparison. 
|1]MySQL Tutorial|DBMS stands for DataBase...| 
|7|Tuning DB2|For IBM database...| 
|8|IBM History|DB2 hitory for IBM...| 
|3|Optimizing MySQL|In this tutorial we will show... | 
|6|MySQL Security|When configured properly,MySQL...| 
|2|How To Use MySQL Well|After you went through a... | 
1212901. MySQL Tricks|1.Never run mysqld as root. Pan 


á rows in set(0.00 sec) 


3 








可 以 看 到 最 后 得 到 8 条 结 末 ， 除 了 之 前 包含 database 的 记录 ， 也 有 包 
含 title 或 body 字 段 中 包含 MySQL、DB2 的 文档 。 这 就 是 Query 
Expansion. 


H T Query Expansion 的 全 文 检索 可 能 市 来 许多 非 相关 性 的 查询 ， 因 
此 在 使 用 时 ， 用 户 可 能 需要 非常 谨慎 。 





59 ”小 结 


本 章 介 绍 了 一 些 第 用 的 数据 结构 ， 如 二 分 查找 树 、 平 衡 树 、 
B+ 树 、 直 接 寻 址 表 和 哈 希 表 ， 以 及 InnoDB1.2 版 本 开始 支持 的 全 文 索 
引 。 从 数据 结构 的 角度 切入 数据 库 中 常见 的 B+ 树 索引 和 哈 希 索引 的 使 
用 ， 并 从 内 部 机 制 上 讨论 了 使 用 上 述 索 引 的 环境 和 优化 方法 。 








HO i 


开发 多 用 户 、 数 据 库 驱 动 的 应 用 时 ， 最 大 的 一 个 难点 是 : 一 方面 要 
最 大 程度 地 利用 数据 库 的 并 发 访问 ， 另 外 一 方面 还 要 确保 每 个 用 户 能 以 
一 致 的 方式 读 取 和 修改 数据 。 为 此 束 有 了 锁 docking) 的 机 制 ， 同 时 这 
也 是 数据 库 系 统 区 别 于 文件 系统 的 一 个 关键 特性 。InnoDB 存 储 引 擎 较 
之 MySQL 数 据 库 的 其 他 存储 引擎 在 这 方面 技 高 一 筹 ， 其 实现 方式 非常 
类 似 于 Oracle 数 据 库 。 而 只 有 正确 了 解 这 些 锁 的 内 部 机 制 才能 充分 发 挥 
InnoDB 存 储 引 擎 在 锁 方 面 的 优势 。 


这 一 章 将 详细 介绍 InnoDB 存 储 引 擎 对 表 中 数据 的 锁定 ， 同 时 分 析 
InnoDB 存 储 引擎 会 以 怎样 的 粒度 锁定 数据 。 本 章 还 对 MyISAM、 
Oracle, SQL Server 之 间 的 锁 进 行 了 比较 ， 主 要 是 为 了 消除 关于 行 级 锁 
的 一 个 “神话 ”: 人 们 认为 行 级 锁 总 会 增加 开销 。 实 际 上 ， 只 有 当 实 现 本 
吴 会 增加 开销 时 ， 行 级 锁 才 会 增加 开销 。InnoDB 存 储 引 擎 不 需要 锁 升 
级 ， 因 为 一 个 锁 和 多 个 锁 的 开销 是 相同 的 。 

















61 什么 是 锁 


锁 是 数据 库 系统 区 别 于 文件 系统 的 一 个 关键 特性 。 锁 机 制 用 于 管理 
对 共享 资源 的 并 发 访问 J。InnoDB 存 储 引 敬 会 在 行 级 别 上 对 表 数 据 上 
锁 ， 这 固然 不 错 。 不 过 InnoDB 存 储 引 擎 也 会 在 数据 库 内 部 其 他 多 个 地 
方 使 用 锁 ， 从 而 允许 对 多 种 不 同 资源 提供 并 发 访问 。 例 如 ， 操 作 绥 冲 池 
中 的 LRU 列 表 ， 删 除 、 添 加 、 移 动 LRU 列 表 中 的 元 素 ， 为 了 保证 一 致 
性 ， 必 须 有 锁 的 介入 。 数 据 库 系 统 使 用 锁 是 为 了 文 持 对 共享 资源 进行 并 
发 访问 ， 提 供 数 据 的 完整 性 和 一 致 性 。 


另 一 点 需要 理解 的 是 ， 虽 然 现 在 数据 库 系 统 做 得 越 来 越 类 似 ， 但 是 
有 多 少 种 数据 库 ， 束 可 能 有 多 少 种 锁 的 实现 方法 。 在 SQL 语法 层面 ， 
为 SQL 标准 的 存在 ， 要 熟悉 多 个 关系 数据 库 系 统 并 不 是 一 件 难 事 。 而 对 
于 锁 ， 用 户 可 能 对 某 个 特定 的 关系 数据 库 系 统 的 锁定 模型 有 一 定 的 经 
验 ， 但 这 并 不 意味 着 知道 其 他 数据 库 。 在 使 用 ImnoDB 存 储 引 擎 之 前 ， 
我 还 使 用 过 MySQL 数 据 库 的 MyISAM 和 NDB Cluster 存储 引擎 。 在 使 用 
MySQL 数 据 库 之 前 ， 我 还 曾经 使 用 过 Microsoft SQL Server、Oracle 等 数 
据 库 ， 但 它们 各 上 自 对 于 锁 的 实现 完全 不 同 。 


对 于 MyISAM 引 擎 ， 其 锁 是 表 锁 设计 。 并 发 情况 下 的 读 没 有 问题 ， 
但 是 并 发 插入 时 的 性 能 束 要 差 一 些 了 ， 知 插入 是 在 “底部 ”，MyISAM 存 
储 引擎 还 是 可 以 有 一 定 的 并 发 写 入 操作 。 对 于 Microsoft SQL Server2 Hi 
库 ， 在 Microsoft SQL Server 2005 版 本 之 前 其 都 是 页 锁 的 ， 相 对 表 锁 的 
MyISAM 引 擎 来 说 ， 并 发 性 能 有 上 所 提高 。 页 锁 容 易 实现 ， 然 而 对 于 热点 
数据 页 的 并 发 问题 依然 无 能 为 力 。 到 2005 版 本 ，Microsoft SQL Server 开 
始 文 持 乐观 并 发 和 悲观 并 发 ， 在 乐观 并 发 下 开始 支持 行 级 锁 ， 但 是 其 实 
现 方式 与 InnoDB 存 储 引 擎 的 实现 方式 完全 不 同 。 用 户 会 发 现在 Microsoft 
SQL Server 下 ， 锁 是 一 种 稀有 的 资源 ， 锁 越 多 开销 就 越 大 ， 因 此 它 会 有 
o 在 这 种 情况 下 ， 行 锁 会 升级 到 表 锁 ， 这 时 并 发 的 性 能 又 回 到 了 
以 前 。 

InnoDB 存 储 引 擎 锁 的 实现 和 Oracle 数 据 库 非 常 类 似 ， 提 供 一 致 性 的 
非 锁 定 读 、 行 级 锁 文 持 。 行 级 锁 没 有 相关 人 额外 的 开销 ， 并 可 以 同时 得 到 
并 发 性 和 一 致 性 。 


URET: 这 里 说 的 是 “共享 资源 ”而 不 仅仅 是 “ 行 记录 ”。 














6.2 lock 5latch 


这 里 还 要 区 分 锁 中 容易 令 人 混 消 的 概念 lock 与 jatch。 在 数据 库 中 ， 
lock 与 latch 都 可 以 被 称 为 " 锁 ?”。 但 是 两 者 有 痢 稚 然 不 同 的 含义 ， 本 章 主 
要 关注 的 是 lock。 


latch 一 般 称 为 门 锁 〈 轻 量 级 的 锁 ) ， 因 为 其 要 求 锁 定 的 时 间 必 须 非 
生 短 。 知 持续 的 时 间 长 ， 则 应 用 的 性 能 会 非常 差 。 在 InnoDB 存 储 引擎 
中 ，latch 又 可 以 分 为 mutex 〈 互 斥 量 ) 和 rwlock〈 读 写 锁 ) 。 其 目的 是 
人 Jf Hat BOB 2E BUR DU ES] C 
Il 


lock 的 对 象 是 事务 ， 用 来 锁定 的 是 数据 库 中 的 对 象 ， 如 表 、 页 、 
行 。 并 且 一 般 lock 的 对 象 仅 在 事务 commit 或 rollback 后 进行 释放 《不 同事 
务 隔 离 级 别 释 放 的 时 间 可 能 不 同 ) 。 此 外 ，lock， 正 如 在 大 多 数 数据 库 
中 一 样 ， 是 有 死 锁 机 制 的 。 表 6-1 显 示 了 lock 与 latch 的 不 同 。 
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对 于 InnoDB 存 储 引擎 中 的 latch， 可 以 通过 命令 SHOW ENGINE 
INNODB MUTEX 来 进行 查看 ， 如 图 6-1 所 示 。 


mysql» SHOW ENGINE INNODB MUTEX; 





+ 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 十 
| Type | Name | Status | 
十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 十 


| InnoDB | srv@srv.c:1020 | os waits-5 | 
| InnoDB | log@log.c:833 | os waits-3 | 
十 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 十 一 一 一 一 一 一 一 一 一 一 一 一 十 
2 rows in set (0.03 sec) 

图 6-1 通过 命令 SHOW ENGINE INNODB MUTEX 查 看 latch 


在 Debug 版 本 下 ， 通 过 命令 SHOW ENGINE INNODB MUTEX 可 以 
看 到 latch 的 更 多 信息 ， 如 图 6-2 所 示 。 


mysql> SHOW ENGINE INNODB MUTEX} 

——————————— 
| Type | Nane | Status | 
— d 
| InnoDB | Gkernel.nutex:srvdsrv.c | counted, spin waits=6, spin_rounds=60, os waits=3, os yields=3, os wait times | 
| InnoDB | Logdlog, ¢:833 | os waits=2 | 
| InnoDB | rv lock mutexes | count=0, spin waits=0, spin rounds, os_waits=0, os yleldssü, os wait tinessü | 
a 


3 rows in set (0.01 sec) 





图 6-2 在 Debug 版 本 下 但 看 到 的 latch 


通过 上 述 的 例子 可 以 看 出 ， 列 Type 显 示 的 总 是 InnoDB， 列 Name 显 
示 的 是 latch 的 信息 以 及 所 在 源码 的 位 置 〈 行 数 ) 。 列 Status 比 较 复 杂 ， 


在 Debug 模 式 下 ， 除 了 显示 os_waits， 还 会 显示 count、spin_waits、 
spin_rounds、os_yields、os_wait_times 等 信息 。 其 具体 含义 见 表 6-2。 


$62 mi SHOW ENGINE INNODB MUTEX Sais WM 
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上 述 所 有 的 这 些 信息 都 是 比较 底层 的 ， 一 般 仪 供 开 发 人 员 参 考 。 但 
是 用 户 还 是 可 以 通过 这 些 参数 进行 调 优 。 


相对 于 ]atch 的 查看 ，lock 信 息 就 显得 直观 多 了 。 用 户 可 以 通过 命令 
SHOW ENGINE INNODB STATUS information schema 架 构 下 的 表 
INNODB _TRX、INNODB LOCKS, INNODB LOCK_WAITS 来 观察 锁 











的 信息 。 这 将 在 下 市 中 进行 详细 的 介绍 。 


6.3 ”InnoDB 存 储 引 擎 中 的 锁 
6.3.1 锁 的 类 型 

InnoDB 存 储 引 擎 实现 了 如 下 两 种 标准 的 行 级 锁 : 

口 共 享 锁 CSLock) ， 人 允许 事务 读 一 行 数据 。 

口 排他 锁 CX Lock) ， 人 允许 事务 删除 或 更 新 一 行 数 据 。 

如 果 一 个 事务 T1 已 经 获得 了 行 r 的 共享 锁 ， 那 么 另外 的 事务 T2 可 以 
立即 获得 行 r 的 共享 锁 ， 因 为 读 取 并 没有 改变 行 r 的 数据 ， 称 这 种 情况 为 
MA (Lock Compatible) 。 但 知 有 其 他 的 事务 T3 想 获得 行 z 的 排他 


锁 ， 则 其 必须 等 得 事务 T1、T2 释 放行 r 上 的 共 至 锁 一 一 这 种 情况 称 为 锁 
不 羔 容 。 表 6-3 显 示 了 共 译 锁 和 排他 锁 的 兼容 性 。 








y 
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从 表 6-3 可 以 发 现 X 锁 与 任何 的 锁 都 不 兼容 ， 而 $ 锁 仅 和 S 锁 兼容 。 需 
要 特别 注意 的 是 ，S 和 X 锁 都 是 行 锁 ， 兼 容 是 指 对 同一 记录 Crow) 锁 的 
兼容 性 情况 。 


此 外 ，InnoDB 存 储 引 擎 文 持 多 粒度 〈granular) 锁定 ， 这 种 锁定 允 
许 事 务 在 行 级 上 的 锁 和 表 级 上 的 锁 同 时 存在 。 为 了 支持 在 不 同 粒 度 上 进 
行 加 锁 操 作 ，InnoDB 存 储 引擎 支持 一 种 额外 的 锁 方 式 ， 称 之 为 意 回 锁 
(Intention Lock) 。 意 回 锁 是 将 锁定 的 对 象 分 为 多 个 层次 ， 意 同 锁 意味 


着 事务 希望 在 更 细 粒 度 Cfinegranularity? 上 进行 加 锁 ， 如 图 6-3 所 示 。 


T M 7 : 
Bee 
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图 63 层次 结构 


各 将 上 锁 的 对 象 看 成 一 柠 树 ， 那 么 对 最 下 层 的 对 象 上 锁 ， 也 就 是 对 
最 细 粒 度 的 对 象 进行 上 锁 ， 那 么 首先 需要 对 粗 粒 度 的 对 象 上 锁 。 例 如 图 
6-3， 如 采 需 要 对 页 上 的 记录 r 进 行 上 X 锁 ， 那 么 分 别 需要 对 数据 库 A、 
表 、 页 上 意向 锁 IX， 最 后 对 记录 r 上 X 锁 。 若 其 中 任何 一 个 部 分 导致 等 
待 ， 那 么 该 操作 需要 等 待 粗 粒度 锁 的 完成 。 举 例 来 次， 在 对 记录 zr 加 X 锁 
之 前 ， 已 丝 有 事务 对 表 1 进 行 了 S 表 锁 ， 那 么 表 1 上 已 存在 $ 锁 ， 之 后 事务 
需要 对 记录 r 在 表 1 上 加 上 IX， 由 于 不 羔 容 ， 所 以 该 事务 需要 等 待 表 锁 操 
作 的 完成 。 

InnoDB 和 存储 引 敬 支持 意 癌 锁 设计 比较 简练 ， 其 意向 锁 即 为 表 级 别 
的 锁 。 设 计 目 的 主要 是 为 了 在 一 个 事务 中 揭示 下 一 行将 被 请 求 的 锁 关 
型 。 其 文 持 两 种 意 癌 锁 : 


1) RFE (IS Lock) ， 事 务 想 要 获得 一 张 表 中 茶几 行 的 共享 























锁 





站 
:人 


由 于 ImnoDB 存 储 引 擎 文 持 的 是 行 级 别 的 锁 ， 因 此 意 同 锁 其 实 不 会 
阻塞 除 全 表 扫 以 外 的 任何 请 求 。 故 表 级 意 同 锁 与 行 级 锁 的 兼容 性 如 表 6- 
4 上 所 示 。 
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用 户 可 以 通过 命令 SHOW ENGINE INNODB STATUS £t 
前 锁 请 求 的 信息 : 


“> 
二 
Di 
as 
LIE 





mysql- SHOW ENGINE INNODB STATUS\G; 


Trx id counter 48B89BF 

Purge done for trx's n:0<48B89BA undo n:0<0 

History list length 0 

LIST OF TRANSACTIONS FOR EACH SESSION: 

---TRANSACTION 0,not started,process no 13757,0S thread id 1255176512 

MySQL thread id 42,query id 80424887 localhost root 

show engine innodb status 

---TRANSACTION 48B89BE, ACTIVE 193 sec,process no 13757,0S thread id 1254910272 starting index read 

mysql tables in use 1,locked 1 

LOCK WAIT 2 lock struct(s),heap size 368,1 row lock(s) 

MySQL thread id 41,query id 80424886 localhost root Sending data 

select*from t where a<4 lock in share mode 

------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED: 

RECORD LOCKS space id 30 page no 3 n bits 72 index'PRIMARY'of table'test'.'t'trx id 48B89BE lock mode S waiting 

TABLE LOCK table'test'.'t'trx id 48B89BE lock mode IS 

RECORD LOCKS space id 30 page no 3 n bits 72 index'PRIMARY'of table'test'.'t'trx id 48B89BE lock mode S waiting 

---TRANSACTION 48B89BD,ACTIVE 205 sec,process no 13757,0S thread id 1257838912 

2 lock struct(s),heap size 368,1 row lock(s) 

MySQL thread id 40,query id 80424881 localhost root 

TABLE LOCK table'test'.'t'trx id 48B89BD lock mode IX 

RECORD LOCKS space id 30 page no 3 n bits 72 index'PRIMARY'of table'test'.'t'trx id 48B89BD lock mode X locks rec but not 
gap 





1 row in set(0.01 sec) 





可 以 看 到 SQL 语句 select*from t where a<4 lock in share mode 在 等 


fr, RECORD LOCKS space id 30 page no 3 n bits 72 index PRIMARY 'of 
table'test'.'t'trx id 48B89BD lock mode X locks rec but not gap 表 示 锁 住 的 
资源 。locks rec but not gap 代 表 锁 住 的 是 一 个 索引 ， 不 是 一 个 范围 。 


在 InnoDB 1.0 版 本 之 前 ， 用 户 只 能 通过 命令 SHOW FULL 

PROCESSLIST, SHOW ENGINE INNODB STATUS 等 来 查看 当前 数据 
库 中 锁 的 请 求 ， 然 后 再 判断 事务 锁 的 情况 。 从 InnoDB1.0 开 始 ， 在 
INFORMATION_SCHEMA 架 构 下 添加 了 表 INNODB_TRX、 
INNODB LOCKS. INNODB LOCK_WAITS。 通 过 这 三 张 表 ， 用 户 可 
以 更 简单 地 监控 当前 事务 并 分 析 可 能 存在 的 锁 问 题 。 我 们 将 通过 具体 的 
示例 来 分 析 这 三 张 表 ， 在 之 前 ， 首 先 了 来 看 表 6-5 中 表 INNODB_TRX 的 
定义 ， 其 由 8 个 字段 组 成 。 
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tx requested lock id 
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Be ORAS LE BF 


mysql>SELECT*FROM information schema.INNODB TRX^G; 


ORG ROO IO ROO ROG ROGO KO ROO ROG] c py CR RR Re e RO RR Re Re e ee 


trx mysql thread id:471719 

trx query:select*from parent lock in share mode 
FE HE EFE Je HE E E He E E He FE TCI ICE pup CR RO TOTO IO IOI IO IO 
trx_id:730FEE 

trx state:RUNNING 

trx started:2010-01-04 10:18:37 

trx requested lock id:NULL 

trx wait started:NULL 

trx weight:2 

trx mysql thread id:471718 

trx query:NULL 

2 rows in set(0.00 sec) 











通过 列 state 可 以 观察 到 trx_ 而 
trx_id 为 7311F4 的 事务 日 前 处 于 “LOCK WAIT” 状 态 ， 且 运行 的 SQL 语句 
是 select*from parent lock in share mode。 该 表 内 是 显示 了 当前 运行 的 
InnoDB 事 务 ， 并 不 能 直接 判断 锁 的 一 些 情况 。 如 果 需 要 查看 锁 ， 则 还 
需要 访问 表 INNODB_LOCKS， 该 表 的 字段 组 成 如 表 6-6 所 示 。 





接 者 上 面 的 例子 ， 


FOI ORO KORG RO GRO ROIG III RET row 


= D'my " 
lock index: 'PRIMARY' 
lock e:96 


lock data:i 


$66 $1008 LOCKS HN 








um 
HD 
HD 
ELS 
AER, UT 
Roo 
BERE 
BOCA ci 
SURG. ree NDA NULL 
ANEMIE ese MAREN NULL 
dna doe NOT NULL 


续 查 看 表 INNODB LOCKS: 


FOR kk ck oko oko oko koe ok koe ke ek koe ke ee 


lock id:730FEE:96:3:2 

lock trx id:730FEE 

lock mode:X 

lock type:RECORD 

lock table:'mytest'.'parent' 
lock index:' 





这 次 用 户 可 以 清晰 地 看 到 当前 锁 的 信息 。trx_id 为 730FEE 的 事务 向 
表 parent 加 了 一 个 X 的 行 锁 ，ID 为 7311F4 的 事务 向 表 parent 申 请 了 一 个 $ 
的 行 锁 。lock_data 都 是 1， 申 请 相同 的 资源 ， 因 此 会 有 等 待 。 这 也 可 以 
解释 INNODB_TRX 中 为 什么 一 个 事务 的 trx_state 是 “RUNNING”， 男 一 
个 是 “LOCK WAIT" f, 


另外 需要 特别 注意 的 是 ， 我 发 现 lock_data 这 个 值 并 非 是 “可 信 ” 的 
值 。 例 如 当 用 户 运 行 一 个 范围 查找 时 ，lock_data 可 能 只 返回 第 一 行 的 主 
键 值 。 与 此 同时 ， 如 果 当 前 资源 被 锁 住 了 ， 若 锁 住 的 页 因为 InnoDB 存 
储 引 擎 缓冲 池 的 容量 ， 导 致 该 页 从 缓冲 池 中 被 刷 出 ， 则 查看 
INNODB_LOCKS 表 时 ， 访 值 同样 会 显示 为 NULL， 即 InnoDB 存 储 引 擎 
不 会 从 磁盘 进行 再 一 次 的 查找 。 


在 通过 表 INNODB_LOCKS 查 看 了 每 张 表 上 锁 的 情况 后 ， 用 户 就 可 
以 来 判断 由 此 引发 的 等 待 情况 了 。 当 事务 较 小 时 ， 用 户 就 可 以 人 为 地 、 
直观 地 进行 判断 了 。 但 是 当 事 务 量 非常 大 ， 其 中 锁 和 等 待 也 时 常 发 生 ， 
这 个 时 候 就 不 这 么 容易 判断 。 但 是 通过 表 INNODB_LOCK_WAITS， 可 
以 很 直观 地 反映 当前 事务 的 等 待 。 表 INNODB_LOCK_WAITS 由 4 个 字 
段 组 成 ， 如 表 6-7 所 示 。 


R67 ANNODB LOCK WAITS fit 


Mocking ti 1d 


blocking ti i 








FOI ICICI ROG ROIG KO ROGO] c py CRI RR ROG KO ROIG IO IO IORI RR 


通过 上 述 的 SQL 语句 ， 用 户 可 以 清楚 直观 地 看 到 哪个 事务 阻 哮 了 另 
一 个 事务 。 当 然 ， 这 里 只 给 出 了 事务 和 锁 的 ID 。 如 果 需 要 ， 用 户 可 以 根 
据 表 INNODB _TRX、INNODB LOCKS, INNODB _ LOCK_WAITS 得 到 
更 为 直观 的 详细 人 信息。 例如， 用户 可 以 执行 如 下 联合 查询 : 


OR KO KORR IO ROGO RO ROO ROGO] py CRGO RR ROO KO ROIG ROIG KO ROIG ROG 


6.3.2 — SUP ESE SLE TE 


一 致 性 的 非 锁定 读 〈consistent nonlocking read) 是 指 InnoDB 存 储 引 
擎 通过 行 多 版 本 控制 Cmulti versioning) 的 方式 来 读 取 当前 执行 时 间 数 
据 库 中 行 的 数据 。 如 果 读 取 的 行 正在 执行 DELETE 或 UPDATE 操 作 ， 这 
时 读 取 操作 不 会 因此 去 等 竺 行 上 锁 的 释放 。 相 反 地 ，InnoDB 存 储 引 擎 
会 去 读 取 行 的 一 个 快照 数据 。 如 图 6-4 所 示 。 
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图 6-4 InnoDB 存 储 引擎 非 锁定 的 一 致 性 读 


图 6-4 直 观 地 展现 了 InnoDB 存 储 引 擎 一 致 性 的 非 锁定 读 。 之 所 以 称 
其 为 非 锁 定 读 ， 因 为 不 再 要 等 待 访问 的 行 上 X 锁 的 释放 。 人 快照 数据 是 指 
该 行 的 之 前 版 本 的 数据 ， 该 实现 是 通过 undo 段 来 完成 。 而 undo 用 来 在 事 
务 中 回访 数据 ， 因 此 快照 数据 本 身 是 没有 额外 的 开销 。 此 外 ， 读 取 快 照 
数据 是 不 需要 上 锁 的 ， 因 为 没有 事务 需要 对 历史 的 数据 进行 修改 操作 。 


可 以 看 到 ， 非 锁定 读 机 制 极 大 地 提高 了 数据 库 的 并 发 性 。 在 
InnoDB 存 储 引 擎 的 默认 设置 下 ， 这 是 默认 的 读 取 方式 ， 即 读 取 不 会 占 
用 和 等 待 表 上 的 锁 。 但 是 在 不 同事 务 隔离 级 别 下 ， 读 取 的 方式 不 同 ， 并 
不 是 在 每 个 事务 隅 离 级 别 下 都 是 采用 非 锁定 的 一 致 性 读 。 此 外 ， 即 使 都 
是 使 用 非 锁 定 的 一 致 性 读 ， 但 是 对 于 快照 数据 的 定义 也 各 不 相同 。 


通过 图 6-4 可 以 知道 ， 快 照 数据 其 实 就 是 当前 行 数 据 之 前 的 历史 版 
本 ， 每 行 记录 可 能 有 多 个 版 本 。 束 图 6-4 所 显示 的 ， 一 个 行 记录 可 能 有 
不 正 一 个 快照 数据 ， 一 般 称 这 种 技术 为 行 多 版 本 技术 。 由 此 带 来 的 并 发 
控制 ， 称 之 为 多 版 本 并 发 控制 (Multi Version Concurrency Control, 
MVCC) 
































在 事务 隔离 级 别 READ COMMITTED 和 REPEATABLE 
READ (ImnoDB 存 储 引 擎 的 默认 事务 隅 离 级 别 ) 下 ，InnoDB 存 储 引 擎 使 
用 非 锁定 的 一 致 性 读 。 然 而 ， 对 于 快照 数据 的 定义 却 不 相同 。 在 READ 
COMMITTED 事 务 隅 离 级 别 下 ， 对 于 快照 数据 ， 非 一 致 性 读 总 是 读 取 被 
锁定 行 的 最 新 一 份 快 照 数 据 。 而 在 REPEATABLE READ 事务 隔离 级 别 
下 ， 对 于 快照 数据 ， 非 一 致 性 读 总 是 读 取 事务 开始 时 的 行 数据 版 本 。 来 
J 首先 在 当前 MySQL 数 据 库 的 连接 会 话 A 中 执行 如 下 
SQL 语句 : 








#Session A 

mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>SELECT*FROM parent WHERE id-1; 
*---- 

lid| 

I1 

rugs 


1 row in set(0.00 sec) 


会 话 A 中 已 通过 显 式 地 执行 命令 BEGIN 开 局 了 一 个 事务 ， 并 读 取 了 
表 parent 中 id 为 1 的 数据 ， 但 是 事务 并 没有 结束 。 与 此 同时 ， 用 户 再 开局 
另 一 个 会 话 B， 这 样 可 以 模拟 并 发 的 情况 ， 然 后 对 会 话 B 做 如 下 的 操 





作 : 





mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>UPDATE parent SET id=3 WHERE id=1; 
Query OK,1 row affected(0.00 sec) 

Rows matched:1 Changed:1 Warnings:0 








会 话 B 中 将 事务 表 parent 中 id 为 1 的 记录 修改 为 it=3， 但 是 事务 同 
mds 这 样 id=1 的 行 其 实 加 了 一 个 X 锁 。 这 时 如 果 在 会 话 A 中 再 
次 读 取 id 为 1 的 记录 ， 根 据 InnoDB 存 储 引 擎 的 特性 ， 即 在 READ 
COMMITTED 和 REPEATETABLE READ 的 事务 隔离 级 别 下 会 使 用 非 锁 
定 的 一 致 性 读 。 回 到 之 前 的 会 话 A， 接 着 上 次 未 提交 的 事务 ， 执 行 SQL 
语句 SELECT*FROM parent WHERE id=1 的 操作 ， 这 时 不 管 使 用 READ 
COMMITTEDIE 还 是 REPEATABLE READ 的 事务 隔离 级 别 ， 显 示 的 数据 
应 该 都 是 : 











mysql>SELECT*FROM parent WHERE id=1; 
+----+ 

[ad] 

nu 

nr 


1 row in set(0.00 sec) 





由 于 当前 id=1 的 数据 被 修改 了 1 次 ， 因 此 只 有 一 个 行 版 本 的 记录 。 
接着 ， 在 会 话 B 中 提交 上 次 的 事务 : 





#Session B 
mysql>commit; 
Query OK,0 rows affected(0.01 sec) 








会 话 B 提 交 事 务 后 ， 这 时 在 会 话 A 中 再 运行 SELECT*FROM parent 
id=1 的 SQL 语句 ， 在 READ COMMITTED 和 REPEATABLE 事 务 
隔离 级 别 下 得 到 结果 就 不 一 样 了 。 对 于 READ COMMITTED 的 事务 隔离 
级 别 ， 它 总 是 读 取 行 的 最 新 版 本 ， 如 果 行 被 锁定 了 ， 则 读 取 该 行 版 本 的 
最 新 一 个 快照 (fresh snapshot) 。 在 上 述 例 子 中 ， 因 为 会 话 B 已 经 提交 
了 事务 ， 所 以 READ COMMITTED 事 务 隔 离 级别 下 会 得 到 如 下 结果 : 





mysql>SELECT@@tx_isolation\G; 

FOI TOTO TOTO I ITO IO I AC OWE ERR IRR II III RIAA AE 
@@tx_isolation: READ- COMMITTED 

1 row in set(0.00 sec) 

mysql>SELECT* ERON parent WHERE id=1; 

Empty set(0.00 sec) 





而 对 于 REPEATABLE _ READ 的 事务 隔离 级 别 ， 总 是 读 取 事务 开始 
时 的 行 数据 。 因 此 对 于 REPEATABLE _ READ 事务 隔离 级 别 ， 其 得 到 的 
结果 如 下 : 





mysql>SELECT@@t x_. ewe: 
FOI III III IO IOI IOI Ir d. TOW* A XOOOODOOOOOOOOOOOOOORR 
QQtx isolation: iio tala READ”. 

1 row in set(0.0 


sec) 
mysql> SELECT” EROR parent WHERE id-1; 
Ha 
m 
is 
了 row in set(0.00 sec) 





下 面 将 从 时 间 的 角度 展现 上 述 演示 的 示例 过 程 ， 如 表 6-8 所 示 。 需 
要 特别 注意 的 是 ， 对 于 READ COMMITTED 的 事务 隔离 级 别 而 言 ， 从 数 
o ooo ISSUE 
会 在 第 7 章 进行 详细 的 介 





dus ont: 
i ah iB 
BON 


SELECT * FROM parent 
WHERE id= | 


pL 


BEGIN 


UPDATE parent SET 13 
WHERE id= | 


E 


SELECT * FROM parent 
WHERE id= | 
COMMIT 


=~ 


SELECT * FROM parent 
WHERE id= | 


COMMIT 


oa 


63.8 “一致 性 锁定 读 


在 前 一 小 节 中 讲 到 ， 在 默认 配置 下 ， 即 事务 的 隔离 级 别 为 
REPEATABLE READ 模式 下 ，InnoDB 存 储 引 擎 的 SELECT 操作 使 用 一 
致 性 非 锁定 读 。 但 是 在 某 些 情况 下 ， 用 户 需 要 显 式 地 对 数据 库 读 取 操 作 
进行 加 锁 以 保证 数据 逻辑 的 一 致 性 。 而 这 要 求 数据 库 支持 加 锁 语 句 ， 即 
使 是 对 于 SELECT 的 只 读 操作 。InnoDB 存 储 引 擎 对 于 SELECT 语句 支持 
两 种 一 致 性 的 锁定 读 Clocking read) 操作 : 


LISELECT...FOR UPDATE 











LISELECT...LOCK IN SHARE MODE 


SELECT...FOR UPDATE 对 读 取 的 行 记录 加 一 个 X 锁 ， 其 他 事务 不 
能 对 已 锁定 的 行 加 上 任何 锁 。SELECT...LOCK IN SHARE MODE 对 读 
取 的 行 记录 加 一 个 S 锁 ， 其 他 事务 可 以 癌 被 锁定 的 行 加 S 锁 ， 但 是 如 果 加 
X 锁 ， 则 会 被 阻塞 。 


对 于 一 致 性 非 锁 定 读 ， 即 使 读 取 的 行 已 被 执行 了 SELECT.. .FOR 
UPDATE， 也 是 可 以 进行 读 取 的 ， 这 和 之 前 讨论 的 情况 一 样 。 此 外 ， 
SELECT...FOR UPDATE，SELECT...LOCK IN SHARE MODE 必 须 在 
一 个 事务 中 ， 当 事务 提交 了 ， 锁 也 就 释放 了 。 因 此 在 使 用 上 述 两 名 
SELECT 锁定 语句 时 ， 务 必 加 上 BEGIN，START TRANSACTION 或 者 
SET AUTOCOMMIT=0。 


63.4 自 增 长 与 锁 


自 增 长 在 数据 库 中 是 非常 常见 的 一 种 属性 ， 也 是 很 多 DBA 或 开发 人 
员 首 选 的 主键 方式 。 在 InnoDB 存 储 引 擎 的 内 存 结 构 中 ， 对 每 个 合 有 自 
增长 值 的 表 都 有 一 个 自 增长 计数 器 〈auto-increment counter? 。 当 对 含 
有 上 自 增 长 的 计数 器 的 表 进 行 插 入 操作 时 ， 这 个 计数 器 会 被 切 始 化 ， 执 行 
如 下 的 语句 来 得 到 计数 器 的 值 : 

















SELECT MAX(auto inc col)FROM t FOR UPDATE; 





插入 操作 会 依据 这 个 自 增 长 的 计数 器 值 加 1 赋予 自 增长 列 。 这 个 实 
现 方式 称 做 AUTO-INC Locking。 这 种 锁 其 实 是 采用 一 种 特殊 的 表 锁 机 
制 ， 为 了 提高 插入 的 性 能 ， 锁 不 是 在 一 个 事务 完成 后 才 释 放 ， 而 是 在 完 
成 对 自 增长 值 插入 的 SQL 语句 后 立即 释放 。 


虽然 AUTO-INC Locking 从 一 定 程度 上 提高 了 并 发 插入 的 效率 ， 但 
还 是 存在 一 些 性 能 上 的 问题 。 首 先 ， 对 于 有 自 增长 值 的 列 的 并 发 插入 性 
能 较 差 ， 事 务必 须 等 竺 前 一 个 插入 的 完成 (虽然 不 用 等 待 事务 的 完 
成 ) 。 其 次 ， 对 于 INSERT...SELECT 的 大 数据 量 的 插入 会 影响 插入 的 性 
能 ， 因 为 另 一 个 事务 中 的 插入 会 被 阻塞 。 


从 MySQL “5.1.22 版 本 开始 ，InnoDB 存 储 引 擎 中 提供 了 一 种 轻 量 级 
互 斥 量 的 上 自 增 长 实现 机 制 ， 这 种 机 制 大 大 提高 了 目 增 长 值 插入 的 性 能 。 
并 且 从 该 版 本 开始 ，InnoDB 存 储 引 擎 提供 了 一 个 参数 
innodb autoinc lock_mode 来 控制 和 目 增 长 的 模式 ， 该 参数 的 默认 值 为 1。 
的 自 增 长 实现 方式 之 前 ， 需 要 对 自 增长 的 插入 进行 分 类 ， 
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接着 来 分 析 参 数 innodb_autoinc_ lock_mode 以 及 各 个 设置 下 对 自 增 的 
影响 ， 其 总 共有 三 个 有 效 值 可 供 设 定 ， 即 0、1、2， 有 具体 说 明 如 表 6-10 
所 示 。 





& 0-10 参数 innodb autoinc lock mode AAA 
nnodb auloinc lock mode T 


这 是 MySQLS.1.22 版 本 之 前 自 增长 的 实现 方式 Bl AUTON 
| Locking 方式 ， 因 为 有 了 新 的 自 增长 实现 方式 ，0 这 个 寺 项 不 应 该 是 新 版 用 户 的 首 
tu 
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此 外 ， 还 需要 特别 注意 的 是 InnoDB 存 储 引 擎 中 自 增长 的 实现 和 
MyYISAM 不 同 ，MyISAM 存 储 引 擎 是 表 锁 设计 ， 目 增长 不 用 考 夸 并 发 插 
入 的 问题 。 因 此 在 master 上 用 InnoDB 存 储 引 擎 ， 在 slave 上 用 MyISAM 存 
储 引 擎 的 replication 架 构 下 ， 用 户 必 须 考虑 这 种 情况 。 


另外 ， 在 InnoDB 存 储 引 擎 中 ， 自 增长 值 的 列 必须 是 索引 ， 同 时 必 
须 是 索引 的 第 一 个 列 。 如 果 不 是 第 一 个 列 ， 则 MySQL 数 据 库 会 抛 出 异 
T e a 下 面 的 测试 反映 了 这 两 个 存储 
5 Es E Sir 











mysql>CREATE TABLE t( 
->a INT AUTO_INCREMENT, 

->B INT, 

->KEY(b,a) 

- >)ENGINE=InnoDB; 

ERROR 1075(42000):Incorrect table definition; there can be only one auto column and it must be defined as a key 
mysql>CREATE TABLE t( 

->a INT AUTO INCREMENT, 

->B INT, 

-»KEY(b,a) 

- >) ENGINE=MyISAM; 

Query OK,0 rows affected(0.01 sec) 


es | 


6.3.5 “外 键 和 锁 


前 面 已 经 介绍 了 外 键 ， 外 键 主要 用 于 引用 完整 性 的 约束 检查 。 在 
InnoDB 存 储 引擎 中 ， 对 于 一 个 外 键 列 ， 如 果 没 有 显 式 地 对 这 个 列 加 索 
引 ，InnoDB 存 储 引 和 擎 自动 对 其 加 一 个 索引 ， 因 为 这 样 可 以 避免 表 锁 
这 比 Oracle 数 据 库 做 得 好 ，Oracle 数 据 库 不 会 自动 添加 索引 ， 用 户 
必须 自己 手动 添加 ， 这 也 导致 了 Oracle 数 据 库 中 可 能 产生 死 锁 。 


对 于 外 键 值 的 插入 或 更 新 ， 首 先 需 要 查询 父 表 中 的 记录 ， 即 
SELECT 父 表 。 但 是 对 于 父 表 的 SELECT 操 作 ， 不 是 使 用 一 致 性 非 锁定 
读 的 方式 ， 因 为 这 样 会 发 生 数据 不 一 致 的 问题 ， 因 此 这 时 使 用 的 是 
SELECT...LOCK IN SHARE MODE 方式 ， 即 主动 对 父 表 加 一 个 S 锁 。 如 
条 这 时 父 表 上 已 经 这 样 加 X 锁 ， 子 表 上 的 操作 会 被 阻塞 ， 如 表 6-11 所 
ZN o 
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l DELETE FROM parent WHERE id=} 
| BEGIN 


INSERT INTO child SELECT 23 
| PLNS DINER 
(wating) 





在 上 述 的 例子 中 ， 两 个 会 话 中 的 事务 都 没有 进行 COMMIT 或 
ROLLBACK 操 作 ， 而 会 话 B 的 操作 会 被 阻塞 。 这 是 因为 id 为 3 的 父 表 在 
会 话 A 中 已 经 加 了 一 个 X 锁 ， 而 此 时 在 会 话 B 中 用 户 又 需要 对 父 表 中 id 为 
3 的 行 加 一 个 $ 锁 ， 这 时 INSERT 的 操作 会 被 阻塞 。 设 想 如 果 访 问 父 表 
时 ， 使 用 的 是 一 致 性 的 非 锁定 读 ， 这 时 Session B 会 读 到 父 表 有 id=3 的 记 
录 ， 可 以 进行 插入 操作 。 但 是 如 果 会 话 A 对 事务 提交 了 ， 则 父 表 中 就 不 
存在 id 为 3 的 记录 。 数 据 在 父 、 子 表 就 会 存在 不 一 致 的 情况 。 若 这 时 用 
户 查 询 INNODB_LOCKS 表 ， 会 看 到 如 下 结 








mysql>SELECT*FROM information_schema.INNODB_LOCKS\G; 
JOOOOOOOOOOOOOOOOOOOOOOOOOOR L| pj iSCSI ICICI III I I IAI II IE 
ock_id:7573B8:96:3:4 

ock_trx_id:7573B8 

ock_mode:S 

ock_type:RECORD 

ock table:'mytest'.'parent' 

ock index: 'PRIMARY' 

Ock space:96 


OCk id:7573B3:96:3:4 

OCk trx id:7573B3 
ock_mode:X 

ock_type:RECORD 

ock_table: 'mytest'.'parent' 
ock_index: 'PRIMARY' 
ock_space:96 





2 rows in set(@.00 sec) 


==4 


6.4 锁 的 算法 
6.4.1 行 锁 的 3 种 算法 
InnoDB 存 储 引 擎 有 3 种 行 锁 的 算法 ， 其 分 别 是 : 
口 Record Lock: 单个 行 记 录 上 的 锁 
OGap Lock: 间 隐 锁 ， 锁 定 一 个 范围 ， 但 不 包含 记录 本 丹 


口 Next-Key Lock : Gap Lock*Record Lock， 锁 定 一 个 范围 ， 并 且 锁 
XE WSR AS Er 


Record Lock 总 是 会 去 锁 住 索引 记录 ， 如 果 InnoDB 存 储 引 警 表 在 建 
立 的 时 候 没 有 设置 任何 一 个 索引 ， 那 么 这 时 InnoDB 存 储 引 擎 会 使 用 隐 
式 的 主键 来 进行 锁定 。 


Next-Key Lock 是 结合 了 Gap Lock 和 Record Lock 的 一 种 锁定 算法 ， 
在 Next-Key ”Lock 算 法 下 ，InnoDB 对 于 行 的 查询 都 是 采用 这 种 锁定 算 
法 。 例 如 一 个 索引 有 10，11，13 和 20 这 四 个 值 ， 那 么 该 索引 可 能 被 
Next-Key Locking 的 区 间 为 : 

















采用 Next-Key Lock 的 锁定 技术 称 为 Next-Key Locking。 其 设计 的 目 
的 是 为 了 解决 Phantom Problem， 这 将 在 下 一 小 节 中 介绍 。 而 利用 这 种 锁 
定 技 术 ， 锁 定 的 不 是 单个 值 ， 而 是 一 个 范围 ， 是 谓词 锁 (predict lock) 
的 一 种 改进 。 除 了 next-key locking， 还 有 previous-key locking 技 术 。 同 
样 上 述 的 索引 10、11、13 和 20， 知 采用 previous-key locking, JKA 
可 锁定 的 区 间 为 : 








知事 务 T1 已 经 通过 next-key locking 锁 定 了 如 下 范围 





(10,11]. (11. 13] 





当 插入 新 的 记录 12 时 ， 则 锁定 的 范围 会 变 成 : 





(10,11]. (11,12]. (12. 13] 





然而 ， 当 查询 的 索引 含有 唯一 属性 时 ，InnoDB 存 储 引擎 会 对 Next- 
Key Lock 进 行 优化 ， 将 其 降级 为 Record Lock， 即 仅 锁 住 索 引 本 身 ， 而 不 
是 范围 。 看 下 面 的 例子 ， 首 先 根据 如 下 代码 创建 测试 表 t: 











DROP TABLE IF EXISTS t; 
CREATE TABLE t(a INT PRIMARY KEY); 
INSERT INTO t SELECT 1; 
INSERT INTO t SELECT 2; 
INSERT INTO t SELECT 5; 





接着 来 执行 表 6-12 中 的 SQL 语句 。 





aol E- RS REA 
AE dA zB 
| BEGIN 
l SELCT PROM 
WHERE a=5 FOR UPDATE: 
| BEGIN 
| INSERT INTO SELECT 
| COMIT 
Hi), Ped 
COMMIT 





表 t 共 有 1、2、5 三 个 值 。 在 上 面 的 例子 中 ， 在 会 话 A 中 首先 对 a=5 进 
行 X 锁 定 。 而 由 于 a 是 主键 且 唯 一 ， 因 此 锁定 的 仅 是 5 这 个 值 ， 而 不 是 
(2，5) 这 个 范围 ， 这 样 在 会 话 B 中 插入 值 4 而 不 会 阻 堵 ， 可 以 立即 插入 并 
返回 。 即 锁定 由 Next-Key Lock 算 法 降级 为 了 Record Lock， 从 而 提高 应 
用 的 并 发 性 。 


正如 前 面 所 介绍 的 ，Next-Key Lock 降 级 为 Record Lock 仅 在 查询 的 
列 是 唯一 索引 的 情况 下 。 知 是 辅助 索引 ， 则 情况 会 完全 不 同 。 同 样 ， 首 
先 根据 如 下 代码 创建 测试 表 z: 








CREATE TABLE z(a INT,b INT,PRIMARY KEY(a),KEY(b)); 
INSERT INTO z SELECT 1,1; 
INSERT INTO z SELECT 3,1; 
INSERT INTO z SELECT 5,3; 
INSERT INTO z SELECT 7,6; 
INSERT INTO z SELECT 10,8; 





ALN b xe EUER SI. ATES TEA PUT PÉBBSQLISS: 








SELECT*FROM z WHERE b=3 FOR UPDATE 








很 明显 ， 这 时 SQL 语句 通过 索引 列 b 进 行 查 询 ， 因 此 其 使 用 传统 的 
Next-Key Locking 技 术 加 锁 ， 并 且 由 于 有 两 个 索引 ， 其 需要 分 别 进行 锁 
定 。 对 于 聚集 索引 ， 其 仅 对 列 a 等 于 5 的 索引 加 上 Record Lock。 而 对 于 辅 
助 索 引 ， 其 加 上 的 是 Next-Key Lock， 锁 定 的 范围 是 (1，3)， 特 别 需 要 注 
意 的 是 ，InnoDB 存 储 引 擎 还 会 对 辅助 索引 下 一 个 键 值 加 上 gap lock， 即 
还 有 一 个 辅助 索引 范围 为 3，6) 的 锁 。 因 此 ， 知 在 新 会 话 B 中 运行 下 面 
的 SQL 语句 ， 都 会 被 阻 考 : 








SELECT*FROM z WHERE a=5 LOCK IN SHARE MODE; 
INSERT INTO z SELECT 4,2; 
INSERT INTO z SELECT 6,5; 





第 一 个 SQL 语句 不 能 执行 ， 因 为 在 会 话 A 中 执行 的 SQL 语句 已 经 对 
聚集 索引 中 列 a=5 的 值 加 上 X 锁 ， 因 此 执行 会 被 阻 竖 。 第 二 个 SQL 语句 ， 
主键 插入 4， 没 有 问题 ， 但 是 插入 的 辅助 索引 值 2 在 锁定 的 范围 (1，3) 
中 ， 因 此 执行 同样 会 被 阻塞 。 第 三 个 SQL 语句 ， 揪 入 的 主键 6 没有 被 锁 
定 ，5 也 不 在 范围 (1，3) 之 间 。 但 插入 的 值 5 在 另 一 个 锁定 的 范围 3，6) 
中 ， 故 同样 需要 等 待 。 而 下 面 的 SQL 语句 ， 不 会 被 阻 守 ， 可 以 立即 执 
人行: 





INSERT INTO z SELECT 8,6; 
INSERT INTO z SELECT 2,0; 
INSERT INTO z SELECT 6,7; 





从 上 面 的 例子 中 可 以 看 到 ，Gap Lock 的 作用 是 为 了 阻止 多 个 事务 将 
记录 插入 到 同一 范围 内 ， 而 这 会 导致 Phantom Problem 问 题 的 产生 。 例 如 
在 上 面 的 例子 中 ， 会 话 A 中 用 户 已 经 锁定 了 b=3 的 记录 。 若 此 时 没有 Gap 
Lock 锁 定 (3, 6) ， 那 么 用 户 可 以 插入 索引 b 列 为 3 的 记录 ， 这 会 导致 会 
话 A 中 的 用 户 再 次 执行 同样 查询 时 会 返回 不 同 的 记录 ， 即 导致 Phantom 
Problem 问 题 的 产生 。 











用 户 可 以 通过 以 下 两 种 方式 来 显 式 地 关闭 Gap Lock: 
口 将 事务 的 隔离 级 别 设置 为 READ COMMITTED 
口 将 参数 innodb_ locks_unsafe_for_binlog 设 置 为 1 


在 上 述 的 配置 下 ， 除 了 外 键 约束 和 唯一 性 检查 依然 需要 的 Gap 
Lock， 其 余 情 况 仅 使 用 Record ”Lock 进行 锁定 。 但 需要 牢记 的 是 ， 上 述 
设置 破坏 了 事务 的 隔离 性 ， 并 且 对 于 replication， 可 能 会 导致 主 从 数据 
的 不 一 致 。 此 外 ， 从 性 能 上 来 看 ，READ COMMITTED 也 不 会 优 于 默认 
的 事务 隔离 级 别 READ REPEATABLE。 


在 InnoDB 存 储 引擎 中 ， 对 于 INSERT 的 操作 ， 其 会 检查 插入 记录 的 
下 一 条 记录 是 否 被 锁定 ， 若 已 经 被 锁定 ， 则 不 允许 查询 。 对 于 上 面 的 例 
子 ， 会 话 A 已 经 锁定 了 表 z 中 b=3 的 记录 ， 即 已 经 锁定 了 (1，3) 的 范围 ， 
这 时 若 在 其 他 会 话 中 进行 如 下 的 插入 同样 会 导致 阻塞 : 














INSERT INTO z SELECT 2,2; 





因为 在 辅助 索引 列 b 上 插入 值 为 2 的 记录 时 ， 会 监测 到 下 一 个 记录 3 
己 经 被 索引 。 而 将 插入 修改 为 如 下 的 值 ， 可 以 立即 执行 : 





INSERT INTO z SELECT 2,0; 


最 后 需 再 次 提醒 的 是 ， 对 于 唯一 键 值 的 锁定 ，Next-Key Lock 降 级 
为 Record Lock 仅 存在 于 和 查询 所 有 的 唯一 索引 列 。 大 唯一 索引 由 多 个 列 组 
成 ， 而 查询 仪 是 查找 多 个 唯一 索引 列 中 的 其 中 一 个 ， 那 么 查询 其 实 是 
range 类 型 查询 ， 而 不 是 point 类 型 查询 ， 故 InnoDB 存 储 引擎 依然 使 用 
Next-Key Lock 进 行 锁定 。 

















6.4.2 ”解决 Phantom Problem 


在 默认 的 事务 隔离 级 别 下 ， 即 REPEATABLE READ 下，InnoDB 存 
储 引 擎 采用 Next-Key “Locking 机 制 来 避免 Phantom Problem 〈 约 像 问 
题 ) 。 这 点 可 能 不 同 于 与 其 他 的 数据 库 ， 如 Oracle 数 据 库 ， 因 为 其 可 能 
需要 在 SERIALIZABLE 的 事务 隅 离 级 别 下 才能 解决 Phantom Problem. 


Phantom Problem 是 指 在 同一 事务 下 ， 连 续 执 行 两 次 同样 的 SQL 语句 
可 能 导致 不 同 的 结果 ， 第 二 次 的 SQL 语句 可 能 会 返回 之 前 不 存在 的 行 。 
下 面 将 演示 这 个 例子 ， 使 用 前 一 小 节 所 创建 的 表 t。 表 t 由 1、2、5 这 三 个 
值 组 成 ， 若 这 时 事务 T1 执 行 如 下 的 SQL 语 句 : 








SELECT*FROM t WHERE a>2 FOR UPDATE; 





注意 这 时 事务 T1 并 没有 进行 提交 操作 ， 上 述 应 该 返回 5 这 个 结 
若 与 此 同时 ， 另 一 个 事务 T2 插 入 了 4 这 个 值 ， 并 且 数 据 库 允 许 该 操作 ， 
那么 事务 T1 再 次 执行 上 述 SQL 语 句 会 得 到 结果 4 和 5。 这 与 第 一 次 得 到 的 
结果 不 同 ， 违 反 了 事务 的 隔离 性 ， 即 当前 事务 能 够 看 到 其 他 事务 的 结 
果 。 其 过 程 如 表 6-13 所 示 。 








6-13 Phantom Problem 的 演示 


Fi 


tt 1solation= READ-OMMITTED': 


BEGIN: 


SELECT * FROM 
WHERE a> 2 FOR UPDATE: 


BRRRRRR ARS | row ARERRRRR 


n 








HE ii ai 
- BEGIN: 
j INSERT INTO t SELECT 4 
| COMMIT 
SELECT* FROM t 
WHERE a> 2 FOR UPDATE: 
a a 
| a4 
daii iii 
i) 
InnoDB ffi 5] 25% FA Next-Key Locking 的 算法 避免 Phantom 


Problem。 对 于 上 述 的 SQL 语句 SELECT*FROM t WHERE a>2 FOR 
UPDATE， 其 锁 住 的 不 是 5 这 单个 值 ， 而 是 对 〈2，+oo) 这 个 范围 加 了 X 
锁 。 因 此 任何 对 于 这 个 范围 的 插入 都 是 不 被 允许 的 ， 从 而 避免 Phantom 


Problem. 


InnoDB 存 储 引 警 默 认 的 事务 隔离 级 别 是 REPEATABLE READ, 在 
该 隔离 级 别 下 ， 其 采用 Next-Key Locking 的 方式 来 加 锁 。 而 在 事务 隔离 





级 别 READ COMMITTED 下 ， 其 仅 采 用 Record Lock， 因 此 在 上 述 的 示 
例 中 ， 会 话 A 需 要 将 事务 的 隔离 级 别 设 置 为 READ COMMITTED. 


此 外 ， 用 户 可 以 通过 InnoDB 存 储 引 擎 的 Next-Key Locking 机 制 在 应 
用 层面 实现 唯一 性 的 检查 。 例 如 : 





SELECT*FROM table WHERE col=xxx LOCK IN SHARE MODE 
If not found any row: 


#unique for insert value 
INSERT INTO table VALUES(...); 





如 果 用 户 通 过 索引 查询 一 个 值 ， 并 对 该 行 加 上 一 个 SLock， 那 么 即 
使 查询 的 值 不 在 ， 其 锁定 的 也 是 一 个 范围 ， 因 此 若 没 有 返回 任何 行 ， 那 
么 新 插入 的 值 一 定 是 唯一 的 。 也 许 有 读者 会 有 疑问 ， 如 果 在 进行 第 一 步 
SELECT...LOCK IN SHARE MODE 操 作 时 ， 有 多 个 事务 并 发 操作 ， 那 
么 这 种 唯一 性 检查 机 制 是 否 存在 问题 。 其 实 并 不 会 ， 因 为 这 时 会 导致 死 
锁 ， 只 有 一 个 事务 的 插入 操作 会 成 功 ， 而 其 余 的 事务 会 抛 出 死 锁 的 错 
误 ， 如 表 6-14 所 示 。 








# 6.14 ul ocking 实现 应 用 程序 的 中 一 性 检查 
SAB 


| BEGIN 


my SELECT * FROM 2 


l WHERE b=4 
LOCK IN SHARE MODE, 


mys SELECT * FROM 2 
j WHERE b=4 
LOCK IN SHARE MODE, 


^" SERT INTO 2 SELECT 44 





| 
mysqbINSERT INTO z 
SELECT 4 
j ERROR 1213 (40001):Deadlock found when 
trying to get Jocktry restarting transaction 
HUGE 


INSERTA] 


6.5” 锁 问题 


通过 锁定 机 制 可 以 实现 事务 的 隔离 性 要 求 ， 使 得 事务 可 以 并 友 地 工 
作 。 锁 提高 了 并 发 ， 但 是 却 会 带 来 潜在 的 问题 。 不 过 好 在 因为 事务 隔离 
性 的 要 求 ， 锁 只 会 融 来 三 种 问题 ， 如 果 可 以 防止 这 三 种 情况 的 发 生 ， 那 
将 不 会 产生 并 发 异常 。 


6.5.1 HER 


在 理解 脏 读 (Dirty Read) 之 前 ， 需 要 理解 及 数据 的 概念 。 但 是 脏 
数据 和 之 前 所 介绍 的 脏 页 完全 是 两 种 不 同 的 概念 。 脏 页 指 的 是 在 缓冲 池 
中 已 经 被 修改 的 页 ， 但 是 还 没有 刷新 到 磁盘 中 ， 即 数据 库 实 例 内 存 中 的 
页 和 磁盘 中 的 页 的 数据 是 不 一 致 的 ， 当 然 在 刷新 到 磁盘 之 前 ， 日 志 都 已 
经 被 写 入 到 了 重 做 日 志文 件 中 。 而 所 谓 脏 数据 是 指 事务 对 缓冲 池 中 行 记 
录 的 修改 ， 并 且 还 没有 被 提交 (commit) 。 


对 于 脏 页 的 读 取 ， 是 非常 正 常 的 。 脏 页 是 因为 数据 库 实例 内 存 和 磁 
盘 的 异步 造成 的 ， 这 并 不 影响 数据 的 一 致 性 《或 者 说 两 者 最 终 会 达到 一 
致 性 ， 即 当 脏 页 都 刷 回 到 磁盘) 。 并 且 因 为 脏 页 的 刷新 是 异步 的 ， 不 影 
啊 数 据 库 的 可 用 性 ， 因 此 可 以 带 来 性 能 的 提高 。 


脏 数据 却 截 然 不 同 ， 脏 数据 是 指 未 提交 的 数据 ， 如 果 读 到 了 脏 数 
据 ， 即 一 个 事务 可 以 读 到 另外 一 个 事务 中 未 提交 的 数据 ， 则 显然 违反 了 
数据 库 的 隔离 性 。 


脏 读 指 的 就 是 在 不 同 的 事务 下， 当前 事务 可 以 读 到 态 外 事务 未 提交 
pu Educ ditus extent UHR 
I 例子 。 
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ROS EROTA 


SAB 


SET 


MAtx tsohtion read«ncommitted 
BEGIN; 
mysg SELECT * FROM NG; 


HAKKAR ARR | [ow KARR ERR K RRS 
xl 


| row in set (0.00 sec) 


mysql> SELECT * FROM 0; 


RARKARARE | TOW KERRAK RKKK K 
al 
LLELLE EE ] TOW Yoon 
a) 


2 row in set (0.00 sec) 


表 {t 为 我 们 之 前 在 6.4.1 中 创建 的 表 ， 不 同 的 是 在 上 述 例子 中 ， 事 务 
的 隔离 级 别 进 行 了 更 换 ， 由 默认 的 REPEATABLE READ 换 成 了 READ 
UNCOMMITTED。 因 此 在 会 话 A 中 ， 在 事务 并 没有 提交 的 前 提 下 ， 会 
话 B 中 的 两 次 SELECT 操作 取得 了 不 同 的 结果 ， 并 且 2 这 条 记录 是 在 会 话 
A 中 并 未 提交 的 数据 ， 即 产生 了 脏 读 ， 违 反 了 事务 的 隔离 性 。 


脏 读 现象 在 生产 环境 中 并 不 常 发 生 ， 从 上 面 的 例子 中 就 可 以 发 现 ， 
脏 读 发 生 的 条 件 是 需要 事务 的 隔离 级 别 为 READ UNCOMMITTED， 而 
目前 绝 大 部 分 的 数据 库 都 至 少 设置 成 READ COMMITTED。InnoDB 存 
储 引 警 默认 的 事务 隔离 级 别 为 READ REPEATABLE, Microsoft SQL 
Server 数 据 库 为 READ COMMITTED，Oracle 数 据 库 同样 也 是 READ 
COMMITTED. 


脏 读 隔 离 看 似 毫 无 用 处 ， 但 在 一 些 比较 特殊 的 情况 下 还 是 可 以 将 事 
务 的 隔离 级 别 设置 为 READ UNCOMMITTED。 例 如 replication 环 境 中 的 
slave 节 点 ， 并 且 在 该 slave 上 的 查询 并 不 需要 特别 精确 的 返回 值 。 











652 ”不 可 重复 恋 


不 可 重复 读 是 指 在 一 个 事务 内 多 次 读 取 同一 数据 集合 。 在 这 个 事务 
还 没有 结束 时 ， 男 外 一 个 事务 也 访问 该 同一 数据 集合 ， 并 做 了 一 些 
DML 操 作 。 因 此 ， 在 第 一 个 事务 中 的 两 次 读数 据 之 间 ， 由 于 第 二 个 事 
务 的 修改 ， 那 么 第 一 个 事务 两 次 读 到 的 数据 可 能 是 不 一 样 的 。 这 样 束 发 
FU NM RUM 
jm 


不 可 重复 读 和 脏 读 的 区 别 是 : 脏 读 是 读 到 未 提交 的 数据 ， 而 不 可 重 
复读 读 到 的 却 是 已 经 提交 的 数据 ， 但 是 其 违反 了 数据 库 事 务 一 致 性 的 要 
求 。 可 以 通过 下 面 一 个 例子 来 观察 不 可 重复 读 的 情况 ， 如 表 6-16 所 示 。 

















R46 TERRA 


im Hi 
| SETA Otx isolation” read-committed" 


SET (Vtx isolation read-committed' 


| BEGIN BEGIN 


mysqlSELECT* FROM t: 


oap | y 六 


| 
M 
| row inset (0,00 sec) 
j INSERT INTO t SELECT 2; 
| COMMIT 
mysql SELECT * FROM 
LLLEELEETÀ | y LLLLLEEEL TIT: 
a| 
] 


ido | TOW HIDIDDDPTÍT: 
1) 


2 row inset (0,00 see 





在 会 话 A 中 开始 一 个 事务 ， 第 一 次 读 取 到 的 记录 是 1， 在 另 一 个 会 
话 B 中 开始 了 另 一 个 事务 ， 插 入 一 条 为 2 的 记录 ， 在 没有 提交 之 前 ， 对 会 
话 A 中 的 事务 进行 再 次 读 取 时 ， 读 到 的 记录 还 是 1， 没 有 发 生 脏 读 的 现 
象 。 但 会 话 B 中 的 事务 提交 后 ， 在 对 会 话 A 中 的 事务 进行 读 取 时 ， 这 时 
读 到 是 1 和 2 两 条 记录 。 这 个 例子 的 前 提 是 ， 在 事务 开始 前 ， 会 话 A 和 会 
话 B 的 事务 隔离 级 别 都 调整 为 READ COMMITTED. 




















一 般 来 说 ， 不 可 重复 读 的 问题 是 可 以 接受 的 ， 因 为 其 读 到 的 是 已 经 
提交 的 数据 ， 本 身 并 不 会 带 来 很 大 的 问题 。 因 此 ， 很 多 数据 库 厂商 (如 
Oracle. Microsoft SQL Server) 将 其 数据 库 事 务 的 默认 隔离 级 别 设置 为 
READ COMMITTED， 在 这 种 隔离 级 别 下 人 允许 不 可 重复 读 的 现象 。 


在 mnoDB 存 储 引 擎 中 ， 通 过 使 用 Next-Key Lock 算 法 来 避免 不 可 重 
复读 的 问题 。 在 MySQL 官 方 文档 中 将 不 可 重复 恋 的 问题 定义 为 Phantom 
Problem， 即 幻像 问题 。 在 Next-Key Lock 算 法 下 ， 对 于 索引 的 扫描 ， 不 
仅 是 锁 住 扫描 到 的 索引 ， 而 且 还 锁 住 这 些 索引 黎 兰 的 范围 〈gap) 。 
此 在 这 个 范围 内 的 插入 都 是 不 允许 的 。 这 样 就 避免 了 另外 的 事务 在 这 个 
范围 内 插入 数据 导致 的 不 可 重复 读 的 问题 。 因 此 ，InnoDB 存 储 引 擎 的 
默认 事务 隔离 级 别 是 READ REPEATABLE， 采 用 Next-Key Lock 算 法 ， 
避免 了 不 可 重复 读 的 现象 。 








65.3 AA UNT 


丢失 更 新 是 万 一 个 锁 导 致 的 问题 ， 简 单 来 说 其 就 是 一 个 事务 的 更 新 
从 而 导致 数据 的 不 一 致 。 例 
H: 


D 事务 T1 将 行 记录 Ir 更 新 为 v1， 但 是 事务 T1 并 未 提交 。 

2) 与 此 同时 ， 事 务 T2 将 行 记录 Ir 更 新 为 v 2， 事务 T2 未 提交 。 

3) 事务 T1 提 交 。 

4) 事务 T2 提 交 。 

但 是 ， 在 当前 数据 库 的 任何 隔离 级 别 下 ， 都 不 会 导致 数据 库 理论 意 
义 上 的 丢失 更 新 问题 。 这 是 因为 ， 即 使 是 READ UNCOMMITTED 的 事 
务 隔离 级 别 ， 对 于 行 的 DML 操 作 ， 需 要 对 行 或 其 他 粗 粒 度 级 别 的 对 象 
加 锁 。 因 此 在 上 述 步 又 2) 中 ， 事 务 T2 并 不 能 对 行 记录 Ir 进行 更 新 操作 ， 
其 会 被 阻塞 ， 直 到 事务 T1 提 交 。 

虽然 数据 库 能 阻止 丢失 更 新 问题 的 产生 ， 但 是 在 生产 应 用 中 还 有 男 
一 个 逻辑 意义 的 丢失 更 新 闻 题 ， 而 导致 该 问题 的 并 不 是 因为 数据 库 本 身 
的 问题 。 实 际 上 ， 在 所 有 多 用 户 计算 机 系统 环境 下 都 有 可 能 产生 这 个 问 
题 。 简 单 地 说 来 ， 出 现下 面 的 情况 时 ， 就 会 发 生 技 失 更 新 : 


1) 事务 T1 碍 询 一 行 数据 ， 放 入 本 地 内 存 ， 并 显示 给 一 个 终端 用 户 
Userl. 


2) 事务 T2 也 碍 询 该 行 数据 ， 并 将 取得 的 数据 显示 给 终端 用 户 
User2. 


3) Userl 修 改 这 行 记 录 ， 更 新 数据 库 并 提交 。 
4) User2 修 改 这 行 记录 ， 更 新 数据 库 并 提交 。 


显然 ， 这 个 过 程 中 用 户 Userl 的 修改 更 新 操作 “丢失 ”了 ， 而 这 可 能 
会 导致 一 个 “恐怖 ”的 结果 。 设 想 银 行 发 生 丢失 更 新 现象 ， 例 如 一 个 用 户 
































账号 中 有 10 000 元 人 民 币 ， 他 用 两 个 网 上 银行 的 客户 端 分 别 进行 转账 操 
作 。 第 一 次 转账 9000 人 民 币 ， 因 为 网 络 和 数据 的 关系 ， 这 时 需要 等 待 。 

但 是 这 时 用 户 操作 另 一 个 网 上 银行 客户 端 ， 转 账 1 元 ， 如 果 最 终 两 笔 操 

作 都 成 功 了 ， 用 户 的 账号 余 款 是 9999 人 民 币 ， 第 一 次 转 的 9000 人 民 币 并 
没有 得 到 更 新 ， 但 是 在 转账 的 另 一 个 账号 却 会 收 到 这 9000 元 ， 这 导致 的 
结果 就 是 钱 变 多 ， 而 账 不 平 。 也 许 有 读者 会 说 ， 不 对 ， 我 的 网 银 是 绑 定 
USB Key 的 ， 不 会 发 生 这 种 情况 。 是 的 ， 通 过 USB Key 登 录 也 许可 以 解 
决 这 个 问题 ， 但 是 更 重要 的 是 在 数据 库 层 解决 这 个 问题 ， 避 免 任 何 可 能 
发 生 丢 失 更 新 的 情况 。 


要 避免 去 失 更 新 有 发生， 需要 让 事务 在 这 种 情况 下 的 操作 变 成 串 行 
化 ， 而 不 是 并 行 的 操作 。 即 在 上 述 四 个 步骤 的 1) 中 ， 对 用 户 读 取 的 记 
录 加 上 一 个 排他 X 锁 。 同 样 ， 在 步骤 2) 的 操作 过 程 中 ， 用 户 同 样 也 需 
要 加 一 个 排他 X 锁 。 通 过 这 种 方式 ， 步 骤 2) 束 必 须 等 待 一 步骤 1) HUP 
又 3) 完成 ， 最 后 完成 步骤 4) 。 表 6-17 所 示 的 过 程 演示 了 如 何 避 免 这 种 
逻辑 上 丢失 更 新 问题 的 产生 。 
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KOT TAPAS 


BEGIN, 


SELECT cash into (cash 


FROM account 
WHERE user = pUser FOR UPDATE; 


UPDATE account 


SET cash=(Ccash-9000 


WHERE user=pUser 


COMMIT 








A B 


SELECT cash into (cash 
FROM account 
WHERE user = pUser FOR UPDATE; 


UPDATE account SET cash=(@cash-| 
WHERE user=pUser 


COMMIT 


有 读者 可 能 会 问 ， 在 上 述 的 例子 中 为 什么 不 直接 允许 UPDATE 语 
句 ， 而 首先 要 进行 SELECT...FOR ” ”UPDATE 的 操作 。 的 确 ， 直 接 使 用 
UPDATE 可 以 避免 丢失 更 新 问题 的 产生 。 然 而 在 实际 应 用 中 ， 应 用 程序 
可 能 需要 首先 检测 用 户 的 余额 信息 ， 查 看 是 否 可 以 进行 转账 操作 ， 然 后 
再 进行 最 后 的 UPDATE 操 作 ， 因 此 在 SELECT 与 UPDATE 操 作 之 间 可 能 
还 存在 一 些 其 他 的 SQL 操作 。 


我 发 现 ， 程 序 员 可 能 在 了 解 如 何 使 用 SELECT、INSERT、 
UPDATE、DELETE 语 句 后 束 开 始 编写 应 用 程序 。 因 此 ， 丢 失 更 新 是 程 
序 员 最 容易 犯 的 错误 ， 也 是 最 不 易 发 现 的 一 个 错误 ， 因 为 这 种 现象 只 是 
随机 的 、 零 星 出 现 的 ， 不 过 其 可 能 造成 的 后 果 却 十 分 严重 。 











6.6 HE 


因为 不 同 锁 之 间 的 兼容 性 关系 ， 在 有 些 时 刻 一 个 事务 中 的 锁 需 要 等 
待 男 一 个 事务 中 的 锁 释 放 它 所 占用 的 资源 ， 这 就 是 阻 窒 。 阻 墅 并 不 是 一 
件 坏事 ， 其 是 为 了 确保 事务 可 以 并 发 且 正 币 地 运行 。 


在 InnoDB 存 储 引 擎 中 ， 参 数 innodb lock_wait_timeout 用 来 控制 等 待 
的 时 间 〈 默 认 是 50 秒 ) , innodb rollback_on_timeonut 用 来 设 定 是 否 在 等 
竺 超时 时 对 进行 中 的 事务 进行 回 滚 操作 “〈 默 认 是 OFF， 代 表 不 回 滚 ) 。 
参数 innodb_lock_wait_timeout 是 动态 的 ， 可 以 在 MySQL 数 据 库 运 行 时 进 
行 调整 : 











mysql>>SET@@innodb_lock_wait_ timeout-60; 
Query OK,0 rows affected(0.00 sec) 





而 innodb_rollback_on_timeout 是 静态 的 ， 不 可 在 局 动 时 进行 修改 ， 
如 : 





mysql>SET@@innodb_rollback_on_timeout=on; 
ERROR 1238(HY000):Variable'innodb rollback on timeout'is a read only variable 





当 发 生 超 时 ，MySQL 数 据 库 会 抛 出 一 个 1205 的 错误 ， 如 : 





mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 

mysql>SELECT*FROM t WHERE a=1 FORUPDATE; 

ERROR 1205(HY000):Lock wait timeout exceeded;try restarting transaction 














AAT, CRU MAR FInnoDB Az NS SE Ze ECRIRE TL 
的 错误 异常 。 其 实 ImnoDB 存 储 引擎 在 大 部 分 情况 下 都 不 会 对 异常 进行 
回 滚 。 如 在 一 个 会 话 中 执行 了 如 下 语句 ， 








# 会 话 A 
mysql>SELECT*FROM t; 
+- - -+ 


十 - - -十 

3 rows in set(0.00 sec) 

mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>SELECT*FROM t WHERE a<4 FOR UPDATE; 
十 - - -十 


1al 


*--- 

11 

121 

十 - - -二 

2 rows in set(0.00 sec) 








会 话 A 中 开启 了 一 个 事务 ， 在 Next-Key Lock 算 法 下 锁定 了 小 于 4 
em 《其 实 也 锁定 了 4 这 个 记录 本 身 ) 。 在 另 一 个 会 话 B 中 执行 如 
下 语 HJ: 





# 会 话 B 

mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 

mysql> INSERT INTO t SELECT 5; 

Query OK,1 row affected(0.00 sec) 

Records: 1 Duplicates:0 Warnings:0 

mysql>INSERTINTO t SELECT 3; 

ERROR 1205(HY000):Lock wait ‘timeout exceeded; try restarting transaction 





可 以 看 到 ， 在 会 话 B 中 插入 记录 5 是 可 以 的 ， 但 是 在 插入 记录 3 时 ， 
话 A 中 Next-Key Lock 算 法 的 关系 ， 需 要 等 待 会 话 A 中 事务 释放 这 

资源 ， 所 以 等 竺 后 产生 了 超时 。 但 是 在 超时 后 用 户 再 进行 SELECT 操 
f EUR. 5 这 个 记录 依然 存在 : 











mysql>SELECT*FROM t; 
*--- 


- -十 
5 rows in set(0.00 sec) 








这 是 因为 这 时 会 话 B 中 的 事务 虽然 执 出 了 异常 ， 但 是 既 没 有 进行 
COMMIT 操 作 ， 也 没有 进行 ROLLBACK。 而 这 是 十 分 危险 的 状态 ， 因 
此 用 户 必 须 判 断 是 否 需要 COMMIT 还 是 ROLLBACK， 之 后 再 进行 下 一 
步 的 操作 。 


67 ZEW 


6.7. 死 锁 的 概念 


和 死 锁 是 指 两 个 或 两 个 以 上 的 事务 在 执行 过 程 中 ， 因 争夺 锁 资 源 而 造 
成 的 一 种 互相 等 待 的 现象 。 大 无 外 力作 用 ， 事 务 都 将 无 法 推进 下 去 。 解 
决 死 锁 问题 最 简单 的 方式 是 不 要 有 等 待 ， 将 任何 的 等 待 都 转化 为 回 滚 ， 
并 且 事 务 重 新 开始 。 齐 无 疑问 ， 这 的 确 可 以 避免 死 锁 问题 的 产生 。 然 而 
在 线 上 环境 中 ， 这 可 能 导致 并 友 性 能 的 下 降 ， 甚 至 任何 一 个 事务 都 不 能 
A aa a 

浪费 资源 。 


解决 死 锁 问题 最 简单 的 一 种 方法 是 超时 ， 即 当 两 个 事务 互相 等 待 
时 ， 当 一 个 等 待 时 间 超 过 设置 的 某 一 冰 值 时 ， 其 中 一 个 事务 进行 回 滚 ， 
男 一 个 等 待 的 事务 就 能 继续 进行 。 在 InnoDB 存 储 引 擎 中 ， 参 数 
innodb_lock_wait_timeout 用 来 设置 超时 的 时 间 。 


超时 机 制 虽然 简单 ， 但 是 其 仅 通 过 超时 后 对 事务 进行 回 深 的 方式 来 
处 理 ， 或 者 说 其 是 根据 FIFO 的 顺序 选择 回 滩 对 象 。 但 大 超时 的 事务 所 占 
权重 比较 大 ， 如 事务 操作 更 新 了 很 多 行 ， 占 用 了 较 多 的 undo log， 这 时 
玉 用 FIFO 的 方式 ， 就 显得 不 合适 了 ， 因 为 回 深 这 个 事务 的 时 间 相对 男 一 
个 事务 所 占用 的 时 间 可 能 会 很 多 。 

因此 ， 除 了 超时 机 制 ， 当 前 数据 库 还 都 普 壳 采用 wait-for graph 等 
待 图 ) 的 方式 来 进行 死 锁 检 测 。 较 之 超时 的 解决 方案 ， 这 是 一 种 更 为 主 
动 的 死 锁 检测 方式 。InnoDB 存 储 引 擎 也 采用 的 这 种 方式 。waitrfor graph 
要 求 数据 库 保 存 以 下 两 种 信息 : 

口 锁 的 信息 链表 

口 事务 等 行 链表 

通过 上 述 链表 可 以 构造 出 一 张 图 ， 而 在 这 个 图 中 知 存 在 回路 ， 就 代 
表 存 在 死 锁 ， 因 此 资源 间 相 互 发 生 等 待 。 在 wait-for graph 中 ， 事 务 为 图 
中 的 节点 。 而 在 图 中 ， 事 务 T1 指 向 T2 边 的 定义 为 : 


口 事 务 T1 等 待 事务 T2 所 占用 的 资源 

















DD 事务 T1 最 终 等 待 T2 所 占用 的 资源 ， 也 就 是 事务 之 间 在 等 待 相同 
的 资源 ， 而 事务 T1 发 生 在 事务 T2 的 后 面 


下 面 来 看 一 个 例子 ， 当 前 事务 和 锁 的 状态 如 图 6-5 所 示 。 


Transaction Lock Lists 
Wait Lists row] 





图 6-5 示例 事务 状态 和 锁 的 信息 


在 Transaction Wait Lists 中 可 以 看 到 共有 4 个 事务 tl1、t2、t3、t4， 故 
在 wait-for ”graph 中 应 有 4 个 节点 。 而 事务 t 世 对 row1 占 用 x 锁 ， 事 务 t1 对 
row2 占 用 s 锁 。 事 务 t1 需 要 等 待 事务 t2 中 row1 的 资源 ， 因 此 在 wait-for 
graph 中 有 条 边 从 节点 t1 指 向 节点 {2。 事 务 t2 需 要 等 待 事 务 t1、t4 所 占用 的 
row2 对 象 ， 故 而 存在 节点 t2 到 节点 t1、t4 的 边 。 同 样 ， 存 在 节点 t3 到 节点 














tL、t2、t4 的 边 ， 因 此 最 终 的 wait-for graph 如 图 6-6 所 示 。 


图 6-6 wait-for graph 


过 图 6-6 可 以 发 现存 在 回路 (t1, CO ， 因 此 存在 死 锁 。 通 过 上 述 
的 介绍 ， 可 以 发 现 wait- for graphzé — MEAE SABES NUT 在 每 
个 事务 请 求 锁 并 发 生 等 待 时 都 会 判断 是 否 存 在 回路 ， 知 存在 则 有 死 锁 ， 
通常 来 说 InnoDB 存 储 引 EHE 回 深 undo 量 最 小 的 事务 。 


wait-for graph 的 死 锁 检测 通常 采用 深度 优先 的 算法 实现 ， 在 
InnoDB1.2 版 本 之 前 ， 都 是 采用 递归 方式 实现 。 而 从 1.2 版 本 开始 ， 对 
wait-for graph 的 死 锁 检测 进行 了 优化 ， 将 递归 用 非 北 归 的 方式 实现 ， 从 
而 进一步 提高 了 InnoDB 存 储 引 擎 的 性 能 。 





6.7.2 JU BUE 


死 锁 应 该 非常 少 发 生 ， 耕 经 常 及 生 ， 则 系统 是 不 可 用 的 。 此 外 ， 死 
锁 的 次 数 应 该 还 要 少 于 等 待 ， 因 为 至 少 需要 2 次 等 竺 才 会 产生 一 次 死 
锁 。 本 节 将 从 纯 数 学 的 概率 角度 来 分 机 ， 死 锁 发 生 的 概率 是 非常 小 的 。 


假设 当前 数据 库 中 共有 n+1 个 线程 执行 ， 即 当前 总 共有 n+1 个 事务 。 
并 假设 每 个 事务 所 做 的 操作 相同 。 耕 每 个 事务 由 r+1 个 操作 组 成 ， 每 个 
操作 为 从 R 行 数据 中 随机 地 操作 一 行 数据 ， 并 占用 对 象 的 锁 。 每 个 事务 
在 执行 完 最 后 一 个 步 又 释放 所 占用 的 所 有 锁 资 源 。 最 后 ， 假 设 nr< < 
R， 即 线程 操作 的 数据 只 占 所 有 数据 的 一 小 部 分 。 


在 上 述 的 模型 下 ， 事 务 获 得 一 个 锁 需 要 等 竺 的 概率 是 多 少 呢 ? 当 事 
务 获得 一 个 锁 ， 其 他 任何 一 个 事务 获得 锁 的 情况 为 : 











人 2 





由 于 每 个 操作 为 从 R 行 数据 中 取 一 条 数据 ， 每 行 数据 被 取 到 的 概率 
为 UR， 因 此， 事务 中 每 个 操作 需要 等 待 的 概率 PW 为 : 


PW=nr/2R 


事务 是 由 r 个 操作 所 组 成 ， 因 此 事务 发 生 等 待 的 概率 PW(T) 为 : 





nr? 
W(T)-1-(1-PW)' ~ r*PW == 
PW(T)-1-(1-PW) r*P OR 


死 锁 是 由 于 产生 回路 ， 也 就 是 事务 互相 等 竺 而 发 生 的 ， 知 死 锁 的 长 
度 为 2， 即 两 个 等 待 节点 间 发 生死 锁 ， 那 么 其 概率 为 : 





2 4 
W uh Jur dz ? nr 
一 个 事务 发 生死 锁 的 概率 ~ 一 T 





由 于 大 部 分 死 锁 发 生 的 长 度 为 2， 因 此 上 述 公式 基本 代表 了 一 个 事 
务 发 生死 锁 的 概率 。 从 整个 系统 来 看 ， 任 何 一 个 事务 发 生死 锁 的 概率 


mr 


系统 中 任何 一 个 事务 发 生死 锁 的 概率 一 了 





从 上 述 的 公式 中 可 以 发 现 ， 由 于 nr 和 <R， 因 此 事务 发 生死 锁 的 概 
率 是 非常 低 的 。 同 时 ， 事 务 发 生死 锁 的 概率 与 以 下 几 点 因素 有 关 : 


口 系统 中 事务 的 数量 OO ， 数 量 越 多 发 生死 锁 的 概率 越 大 。 


口 每 个 事务 操作 的 数量 GO ， 每 个 事务 操作 的 数量 越 多 ， 发 生死 
锁 的 概率 越 大 。 


口 操 作 数 据 的 集合 CORO ， 越 小 则 发 生死 锁 的 概率 越 大 。 





6.7.3 SEAN ZA 


如 果 程 序 是 串 行 的 ， 那 么 不 可 能 发 生死 锁 。 死 锁 只 存在 于 并 发 的 情 
况 ， 而 数据 库 本 和 映 束 是 一 个 并 发 运行 的 程序 ， 因 此 可 能 会 发 生死 锁 。 表 
6-18 的 操作 演示 了 死 锁 的 一 种 经 典 的 情况 ， 即 A 等 待 B，B 在 等 待 A， 这 
种 死 锁 问题 被 称 为 AB-BA 死 锁 。 








$640. TAAN 


ZAB 
mysg SELECT * FROM t 
WHERE a= 1 FOR UPDATE; 
RARER ERB | row ORELE EE EREE BEGIN 
tl 
| row in set (0.00 sec) 
mysql>SELECT * FROM t 


WHERE a = 2 FOR UPDATE; 

HAR KR KE | row BRR RR RR KR RR 

a 

| row in set (0,00 sec) 
mysql>SELECT * FROM t WHERE a = 2 

FOR UPDATE: 


"m 


mysql SELECT * FROM t WHERE a = | 
FOR UPDATE; 

ERROR 1213 (40001): Deadlock found when 
trying to get lock; try restarting transaction 





在 上 述 操作 中 ， 会 话 B 中 的 事务 抛 出 了 1213 这 个 错误 提示 ， 即 表示 
事务 发 生 了 死 锁 。 死 锁 的 原因 是 会 话 A 和 B 的 资源 在 互相 等 待 。 大 多 数 
的 死 锁 InnoDB 存 储 引擎 本 身 可 以 侦 测 到 ， 不 需要 人 为 进行 干预 。 但 是 
在 上 面 的 例子 中 ， 在 会 话 B 中 的 事务 抛 出 死 锁 异 常 后 ， 会 话 A 中 马上 得 
到 了 记录 为 2 的 这 个 资源 ， 这 其 实 是 因为 会 话 B 中 的 事务 发 生 了 回 深 ， 否 
则 会 话 A 中 的 事务 是 不 可 能 得 到 该 资源 的 。 还 记得 6.6 节 中 所 说 的 内 容 
吗 ? InnoDB 存 储 引 擎 并 不 会 回 滚 大 部 分 的 错误 异常 ， 但 是 死 锁 除外 。 
发 现 死 锁 后 ，InnoDB 存 储 引 擎 会 马上 回 滚 一 个 事务 ， 这 点 是 需要 注意 
的 。 因 此 如 果 在 应 用 程序 中 捕获 了 1213 这 个 错误 ， 其 实 并 不 需要 对 其 进 
行 回 滚 。 


Oracle 数 据 库 中 产生 死 锁 的 常见 原因 是 没有 对 外 键 添加 索引 ， 而 
InnoDB 存 储 引 擎 会 目 动 对 其 进行 添加 ， 因 而 能 够 很 好 地 避免 了 这 种 情 
况 的 及 生 。 而 人 为 删除 外 键 上 的 索引 ，MySQL 数 据 库 会 抛 出 一 个 元 


Aw 


n: 





























mysql>CREATE TABLE p( 
->aINT 


7 
->PRIMARY KEY(a) 
- >)ENGINE=InnoDB; 

ery OK,0 rows affected(0.00 sec) 
mysql>CREATE TABLE c( 
> 


->bINT, 
->FOREIGH KEY(b)REFERENCES p(a) 
- >) ENGINE=InnoDB; 
Query OK,0 rows affected(0.00 sec) 
mysql>SHOW INDEX FROM c\G; 


FOI OR KO ROO ROO ROGO KO ROGO] c py Re Ro e eR eR ke e eee 


Null:YES 
Index type:BTREE 
Comment : 

00 sec 


1 ro 
mysql>DROP INDEX b ON c; 
ERROR 1553(HY000):Cannot drop index'b':needed in a foreign key constraint 





通过 上 述 例子 可 以 看 到 ， 虽 然 在 建立 子 表 时 指定 了 外 键 ， 但 是 
InnoDB 存 储 引 擎 会 自动 在 外 键 列 上 建立 了 一 个 索引 b。 并 且 ， 人 为 地 删 
除 这 个 列 是 不 被 允许 的 。 


此 外 还 存在 另 一 种 死 锁 ， 即 当前 事务 持 有 了 竺 插入 记录 的 下 一 个 记 
录 的 X 锁 ， 但 是 在 等 待 队列 中 存在 一 个 S 锁 的 请 求 ， 则 可 能 会 发 生死 
来 看 一 个 例子 ， 首 先 根 据 如 下 代码 创建 测试 表 t， 并 导入 一 些 数 
B: 











CREATE TABLE t( 

a INT PRIMARY KEY 

)ENGINE-InnoDB; 

INSERT INTO t VALUES(1), (2), (4), (5); 








表 {t 仅 有 一 个 列 a， 并 插入 4 条 记录 。 接 着 运行 表 6-19 所 示 的 得 询 。 


SELECT * FROM t 
WHERE a=4 FOR UPDATE; 


SELECT FROM 
WHERE a <= 4 LOCK IN SHARE MODE, 


itl 
"ihi 
INSERT INTO t VALUESG) 


j - ERROR 1213 (40001); Deadlock found when 





trying to get Tock; ry restarting transaction 





可 以 看 到 ， 会 话 A 中 已 经 对 记录 4 持 有 了 X 锁 ， 但 是 会 话 A 中 插入 记 
录 3 时 会 导致 死 锁 发 生 。 这 个 问题 的 产生 是 由 于 会 话 B 中 请 求 记录 4 的 5 
锁 而 发 生 等 待 ， 但 之 前 请 求 的 锁 对 于 主键 值 记录 1、2 都 已 经 成 功 ， 若 在 





事件 点 5 能 插入 记录 ， 那 么 会 话 B 在 获得 记录 4 持 有 的 S 锁 后 ， 还 需要 问 
后 获得 记录 3 的 记录 ， 这 样 就 显得 有 点 不 合理 。 因 此 InnoDB 存 储 引 擎 在 
这 里 主动 选择 了 死 锁 ， 而 回 滚 的 是 undo log 记 录 大 的 事务 ， 这 与 AB-BA 
和 死 锁 的 处 理 方式 又 有 所 不 同 。 





6.8 FR 


锁 升级 (Lock Escalation) 是 指 将 当前 锁 的 粒度 降低 。 举 例 来 说 ， 
数据 库 可 以 把 一 个 表 的 1000 个 行 锁 升 级 为 一 个 页 锁 ， 或 者 将 页 锁 升 级 为 
表 锁 。 如 果 在 数据 库 的 设计 中 认为 锁 是 一 种 稀有 资源 ， 而 且 想 避免 锁 的 
开销 ， 那 数据 库 中 会 频繁 出 现 锁 升 级 现象 。 


Microsoft SQL Server 数 据 库 的 设计 认为 锁 是 一 种 稀有 的 资源 ， 在 适 
合 的 时 候 会 自动 地 将 行 、 键 或 分 页 锁 升 级 为 更 粗 粒度 的 表 级 锁 。 这 种 升 
级 保护 了 系统 资源 ， 防 上 上 系统 使 用 太 多 的 内 存 来 维护 锁 ， 在 一 定 程度 上 
是 高 了 效率 


即使 在 Microsoft SQL Server 2005 版 本 之 后 ，SQL Server 数 据 库 文 持 
了 行 锁 ， 但 是 其 设计 和 InnoDB 存 储 引 擎 完全 不 同 ， 在 以 下 情况 下 依然 
可 能 发 生 锁 升 级 : 


口 由 一 名 单独 的 SQL 语句 在 一 个 对 象 上 持 有 的 锁 的 数量 超过 了 效 
值得 注意 的 是 ， 如 果 是 不 同 对 象 ， 则 不 会 发 
HFK 


口 锁 资 源 占 用 的 内 存 超过 了 激活 内 存 的 40% 时 束 会 发 生 锁 升级 


在 Microsoft SQL Server 数 据 库 中 ， 由 于 锁 是 一 种 稀有 的 资源 ， 因 此 
锁 升 级 会 市 来 一 定 的 效率 提高 。 但 是 锁 升 级 带 来 的 一 个 问题 却 是 因为 锁 
粒度 的 降低 而 导致 并 发 性 能 的 降低 。 


InnoDB 存 储 引 擎 不 存在 锁 升 级 的 问题 。 因 为 其 不 是 根据 每 个 记录 
来 产生 行 锁 的 ， 相 反 ， 其 根据 每 个 事务 访问 的 每 个 页 对 锁 进 行 管理 的 ， 
采用 的 是 位 图 的 方式 。 因 此 不 管 一 个 事务 锁 住 页 中 一 个 记录 还 是 多 个 记 
录 ， 其 开销 通常 都 是 一 致 的 。 


假设 一 张 表 有 3 000 000 个 数据 页 ， 每 个 页 大 约 有 100 条 记录 ， 那 么 
总 共有 300 000 000 条 记录 。 奉 有 一 个 事务 执行 全 表 更 新 的 SQL 语 句 ， 则 
需要 对 所 有 记录 加 X 锁 。 若 根据 每 行 记录 产生 锁 对 象 进行 加 锁 ， 并 日 每 
个 锁 占用 10 字 节 ， 则 仅 对 锁 管理 就 需要 差不多 需要 3GB 的 内 存 。 而 
InnoDB 存 储 引擎 根据 页 进行 加 锁 ， 并 采用 位 图 方式 ， 假 设 每 个 页 存储 
的 锁 信息 占用 30 个 字 节 ， 则 锁 对 象 仅 需 90MB 的 内 存 。 由 此 可 见 两 者 对 

































































于 锁 资 源 开销 的 差距 之 大 。 


69 ”小 结 


这 一 草 介 绍 的 内 容 非 党 多， 可 能 会 让 读者 党 得 很 难 ， 甚 至 会 不 时 地 
抓 耳 挠 膨 。 尽 管 锁 本 身 相 当 直 接 ， 但 是 它 的 一 些 副作用 却 不 是 这 样 。 关 
键 是 用 户 再 要 理解 锁 带 来 的 问题 ， 如 丢失 更 新 、 脏 读 、 不 可 重复 读 等 。 
如 果 不 知道 这 一 点 ， 那 么 开发 的 应 用 程序 性 能 就 会 很 差 。 如 果 不 学 会 怎 
样 通过 一 些 命令 和 数据 字典 来 但 看 事务 锁 住 了 哪些 资源 ， 你 可 能 永远 不 
知道 到 抵 发 生 了 什么 事情 ， 可 能 只 是 认为 MySQL 数 据 库 有 时 会 阻 暑 而 
Es 





本 章 在 介绍 锁 的 同时 ， 还 比较 了 MySQL 数 据 库 InnoDB 存 储 引 擎 、 
MyISAM 存 储 引 擎 、Microsoft SQL Server 数 据 库 、Oracle 数 据 库 锁 的 特 
性 。 通 过 这 些 比较 了 解 到 ， 虽 然 每 个 数据 库 在 SQL 语句 层面 上 的 差别 可 
能 不 是 很 大 ， 在 内 部 底层 的 实现 却 各 有 不 同 。 通 过 理解 mnoDB 存 储 引 
a ee 个 高 性 能 、 高 并 发 的 数据 库 应 用 显得 十 分 重要 
0 有 帮助 。 








第 7 章 事务 


事务 (Transaction) 是 数据 库 区 别 于 文件 系统 的 重要 特性 之 一 。 在 
文件 系统 中 ， 如 果 正 在 写 文件 ， 但 是 操作 系统 突然 朋 误 了 ， 这 个 文件 就 
很 有 可 能 被 破坏 。 当 然 ， 有 一 些 机 制 可 以 把 文件 恢复 到 某 个 时 间 点 。 不 
过 ， 如 果 需 要 保证 两 个 文件 同步 ， 这 些 文件 系统 可 能 就 显得 无 能 为 力 
了 。 例 如 ， 在 需要 更 新 两 个 文件 时 ， 更 新 完 一 个 文件 后 ， 在 更 新 完 第 二 
个 文件 之 前 系统 重启 了 ， 束 会 有 两 个 不 同步 的 文件 。 

这 正 是 数据 库 系 统 引 入 事务 的 主要 目的 : 事务 会 把 数据 库 从 一 种 一 
致 状态 转换 为 另 一 种 一 致 状态 。 在 数据 库 提 交工 作 时 ， 可 以 确保 要 么 所 
有 修改 都 已 经 保存 了 ， 要 么 所 有 修改 都 不 保存 。 


InnoDB 存 储 引 擎 中 的 事务 完全 符合 ACID 的 特性 。ACID 是 以 下 4 个 
词 的 缩写 : 


口 原 子 性 (atomicity) 











口 一 致 性 〈consistency ) 

口 隔离 性 Cisolation) 

QAE Cdurability) 

第 6 章 介 绍 了 锁 ， 讨 论 InnoDB 是 如 何 实现 事务 的 隅 离 性 的 。 本 章 主 


要 关注 事务 的 原子 性 这 一 概念 ， 并 说 明 怎 样 正确 使 用 事务 及 编写 正确 的 
事务 应 用 程序 ， 避 免 在 事务 方面 养 成 一 些 不 好 的 习惯 。 


7.1 认识 事务 
7.1.1 概述 


事务 可 由 一 条 非常 简单 的 SQL 语句 组 成 ， 也 可 以 由 一 组 复杂 的 SQL 
语句 组 成 。 事 务 是 访问 并 更 新 数据 库 中 各 种 数据 项 的 一 个 程序 执行 单 
元 。 在 事务 中 的 操作 ， 要 么 都 做 修改 ， 要 么 都 不 做 ， 这 就 是 事务 的 目 
的 ， 也 是 事务 模型 区 别 与 文件 系统 的 重要 特征 之 一 。 


理论 上 说 ， 事 务 有 着 极其 严格 的 定义 ， 它 必须 同时 满足 四 个 特性 ， 
即 通常 所 说 的 事务 的 ACID 特性 。 值 得 注意 的 是 ， 虽 然 理 论 上 定义 了 严 
格 的 事务 要 求 ， 但 是 数据 库 厂商 出 于 各 种 目的 ， 并 没有 严格 去 满足 事务 
的 ACID 标准 。 例 如 ， 对 于 MySQL 的 NDB Cluster 引 擎 来 说 ， 虽 然 其 支持 
事务 ， 但 是 不 满足 D 的 要 求 ， 即 持久 性 的 要 求 。 对 于 Oracle 数 据 库 来 
说 ， 其 默认 的 事务 隔离 级 别 为 READ COMMITTED， 不 满足 I 的 要 求 ， 
即 隔 离 性 的 要 求 。 虽 然 在 大 多 数 的 情况 下 ， 这 并 不 会 导致 严重 的 结 
甚至 可 能 还 会 带 来 性 能 的 提升 ， 但 是 用 户 首先 需要 知道 严谨 的 事务 标 
准 ， 并 在 实际 的 生产 应 用 中 避免 可 能 存在 的 潜在 问题 。 对 于 InnoDB 存 
储 引 擎 而 言 ， 其 默认 的 事务 隔离 级 别 为 READ REPEATABLE, 76408 
循 和 满足 事务 的 ACID 特性 。 这 里 ， 具 体 介 绍 事务 的 ACID 特性 ， 并 给 出 
相关 概念 。 

A (Atomicity) ， 原 子 性 。 在 计算 机 系统 中 ， 每 个 人 都 将 原子 性 视 
为 理所当然 。 例 如 在 C 语 言 中 调用 SQRT 函数 ， 其 要 么 返回 正确 的 平方 
根 值 ， 要 么 返回 错误 的 代码 ， 而 不 会 在 不 可 预知 的 情况 下 改变 任何 的 数 
据 结构 和 人 参数。 如果 SQRT 函 数 被 许多 个 程序 调用 ， 一 个 程序 的 返回 值 
也 不 会 是 其 他 程序 要 计算 的 平方 根 。 


然而 在 数据 的 事务 中 实现 调用 操作 的 原子 性 ， 束 不 是 那么 理所当然 
了 。 例 如 一 个 用 户 在 ATM 机 前 取 球 ， 假 设 取 球 的 流程 为 : 


1) 登录 ATM 机 平台 ， 验 证 密码 。 
2) 从 远程 银行 的 数据 库 中 ， 取 得 账户 的 信息 。 
3) 用 户 在 ATM 机 上 输入 欲 提 取 的 金额 。 





























4) 从 远程 银行 的 数据 库 中 ， 更 新 账户 信息 。 
5) ATMALH X 
6) HP WU. 


整个 取 球 的 操作 过 程 应 该 视 为 原子 操作 ， 即 要 么 都 做 ， 要 么 都 不 
做 。 不 能 用 户 钱 未 从 ATM 机 上 取得 ， 但 是 银行 卡 上 的 钱 已 经 被 扣除 
了 ， 相 信 这 是 任何 人 都 不 能 接受 的 一 种 情况 。 而 通过 事物 模型 ， 可 以 保 
证 该 操作 的 原子 性 。 


原子 性 指 整 个 数据 库 事务 是 不 可 分 割 的 工作 单位 。 只 有 使 事务 中 所 
有 的 数据 库 操 作 都 执行 成 功 ， 才 算 整 个 事务 成 功 。 事 务 中 任何 一 个 SQL 
语句 执行 失败 ， 已 经 执行 成 功 的 SQL 语句 也 必须 撤销 ， 数 据 库 状态 应 该 
退回 到 执行 事务 前 的 状态 。 


如 果 事务 中 的 操作 都 是 只 读 的， 要 保持 原子 性 是 很 简单 的 。 一 旦 发 
生 任何 错误 ， 要 么 重 试 ， 要 么 返回 错误 代码 。 因 为 只 读 操 作 不 会 改变 系 
统 中 的 任何 相关 部 分 。 但 是 ， 当 事务 中 的 操作 需要 改变 系统 中 的 状态 
时 ， 例 如 插入 记录 或 更 新 记录 ， 那 么 情况 可 能 束 不 像 只 读 操 作 那 么 简单 
了 。 如 宋 操作 失败 ， 很 有 可 能 引起 状态 的 变化 ， 因 此 必须 要 保护 系统 中 
并 发 用 户 访 问 受 影响 的 部 分 数据 。 


C (consistency) ， 一 致 性 。 一 致 性 指 事务 将 数据 库 从 一 种 状态 转 
变 为 下 一 种 一 致 的 状态 。 在 事务 开始 之 前 和 事务 结束 以 后 ， 数 据 库 的 完 
整 性 约束 没有 被 破坏 。 例 如 ， 在 表 中 有 一 个 字段 为 姓名 ， 为 唯一 约束 ， 
即 在 表 中 姓名 不 能 重复 。 如 果 一 个 事务 对 姓名 字段 进行 了 修改 ， 但 是 在 
事务 提交 或 事务 操作 发 生 回 滚 后 ， 表 中 的 姓名 变 得 非 唯一 了 ， 这 就 破坏 
了 事务 的 一 致 性 要 求 ， 即 事务 将 数据 库 从 一 种 状态 变 为 了 一 种 不 一 致 的 
状态 。 因 此 ， 事 务 是 一 致 性 的 单位 ， 如 果 事 务 中 某 个 动作 失败 了 ， 系 统 
可 以 目 动 撤销 事务 一 一 返回 初始 化 的 状态 。 


I (isolation) ， 隔 离 性 。 隅 离 性 还 有 其 他 的 称呼 ， 如 并 发 控制 
(concurrency control) 、 可 串 行 化 〈serializability) ~ # Clocking) 
等 。 事 务 的 隔离 性 要 求 每 个 读 写 事 务 的 对 象 对 其 他 事务 的 操作 对 象 能 相 
互 分 离 ， 即 该 事务 提交 前 对 其 他 事务 都 不 可 见 ， 通 常 这 使 用 锁 来 实现 。 
当前 数据 库 系 统 中 都 提供 了 一 种 粒度 锁 (granular lock) 的 策略 ， 人 允许 
事务 仅 锁 住 一 个 实体 对 象 的 子 集 ， 以 此 来 提高 事务 之 间 的 并 发 度 。 









































D (durability) ， 持 久 性 。 事 务 一 旦 提交 ， 其 结果 就 是 永久 性 的 。 
即使 发 生 宕 机 等 故障 ， 数 据 库 也 能 将 数据 恢复 。 需 要 注意 的 是 ， 只 能 从 
事务 本 身 的 角度 来 保证 结果 的 永久 性 。 例 如 ， 在 事务 提交 后 ， 所 有 的 变 
化 都 是 永久 的 。 即 使 当 数 据 库 因为 骨 溃 而 需要 恢复 时 ， 也 能 保证 恢复 后 
提交 的 数据 都 不 会 丢失 。 但 知 不 是 数据 库 本 身 发 生 故 障 ， 而 是 一 些 外 部 
的 原因 ， 如 RAID 卡 损坏 、 自 然 灾 害 等 原因 导致 数据 库 发 生 问 题 ， 那 么 
所 有 提交 的 数据 可 能 都 会 丢失 。 因 此 持久 性 保证 事务 系统 的 高 可 靠 性 
(High Reliability〉， 而 不 是 高 可 用 性 (High Availability) 。 对 于 高 可 
用 性 的 实现 ， 事 务 本 身 并 不 能 保证 ， 需 要 一 些 系统 共同 配合 来 完成 。 














Tia 4E 
从 事务 理论 的 角度 来 说 ， 可 以 把 事务 分 为 以 下 几 种 类 型 : 
am FE% (Flat Transactions) 





口 带 有 保存 点 的 扁平 事务 (Flat Transactions with Savepoints ) 
口 链 事务 (Chained Transactions) 

OgUES A (Nested Transactions) 

口 分 布 式 事务 (Distributed Transactions) 


局 平 事务 (Flat Transaction) 是 事务 类 型 中 最 简单 的 一 种 ， 但 在 实 
际 生产 环境 中 ， 这 可 能 是 使 用 最 为 频繁 的 事务 。 在 局 平 事务 中 ， 所 有 操 
作 都 处 于 同一 层次 ， 其 由 BEGIN WORK 开始 ， 由 COMMIT WORKZ& 
ROLLBACK WORK 结束 ， 其 间 的 操作 是 原子 的 ， 要 么 都 执行 ， 要 么 都 
回 滚 。 因 此 局 平 事务 是 应 用 程序 成 为 原子 操作 的 基本 组 成 模块 。 图 7-1 
显示 了 扁平 事务 的 三 种 不 同 结果 。 





BEGIN WORK BEGIN WORK 
Operation | Operation | 


Operation 2 Operation 2 


BEGIN WORK 


Operation | 


Operation 2 


Operation K 
COMMIT WORK ROLLBACK WORK 





WAA JANE 鼎 用 程 认 要 求人 上 事务 ， 
dA Aen 
BAAS, NAMA 
bi 
图 7-1 局 平 事务 的 三 种 情况 


图 7-1 给 出 了 局 平 事务 的 三 种 情况 ， 同 时 也 给 出 了 在 一 个 典型 的 事 
务 处 理应 用 中 ， 每 个 结 末 大 概 占 用 的 百分比 。 再 次 提醒 ， 局 平 事务 虽然 
简单 ， 但 在 实际 生产 环境 中 使 用 最 为 频繁 。 正 因为 其 简单 ， 使 用 频繁， 
故 每 个 数据 库 系统 都 实现 了 对 扁平 事务 的 支持 。 


局 平 事务 的 主要 限制 是 不 能 提交 或 者 回 深 事 务 的 某 一 部 分 ， 或 分 几 


个 步骤 提交 。 下 面 给 出 一 个 己 平 事务 不 足以 文 持 的 例子 。 例 如 用 户 在 旅 
行 网 站 上 进行 自己 的 旅行 度假 计划 。 用 户 设想 从 杭州 到 意大利 的 佛 罗 伦 


be, 2 PAST ZAI AAPL, me BEA PT PR eB, s 
需要 搭 火车 等 每 。 用 户 预 订 旅 行 度假 的 事务 为 : 


BEGIN WORK 

S1: 预订 杭州 到 上 海 的 高 铁 

S2: 上 海 浦东 国际 机 场 坐 飞 机 ， 预 订 去 米兰 的 航班 

S3: 在 米兰 转 火 车 前 往 佛 罗 伦 萨 ， 预 订 去 佛罗伦萨 的 火车 


但 是 当 用 户 执行 到 S$3 时 ， 发 现 由 于 飞机 到 达 米 兰 的 时 间 太 晚 ， 已 经 
没有 当天 的 火车 。 这 时 用 户 和 希望 在 米兰 当地 住 一 晚 ， 第 二 天 出 发 去 佛 罗 
伦 配 。 这 时 如 果 事 务 为 局 平 事务 ， 则 需要 回 深 之 前 S1、S2、S3 的 三 个 操 
作 ， 这 个 代价 就 显得 有 点 大 。 因 为 当 再 次 进行 该 事务 时 ，S1、S2 的 执行 
计划 是 不 变 的 。 也 就 是 说 ， 如 果 支 持 有 计划 的 回 深 操 作 ， 那 么 就 不 需要 
终止 整个 事务 。 因 此 束 出 现 了 带 有 保存 点 的 局 平 事务 。 


带 有 保存 点 的 扁平 事务 (Flat Transactions with SavepoinO ， 除 了 支 
持 遍 平 事务 文 持 的 操作 外 ， 人 允许 在 事务 执行 过 程 中 回 深 到 同一 事务 中 较 
早 的 一 个 状态 。 这 是 因为 某 些 事务 可 能 在 执行 过 程 中 出 现 的 错误 并 不 会 
导致 所 有 的 操作 都 无 效 ， 放 弃 整 个 事务 不 合乎 要 求 ， 开 销 也 太 大 。 保 存 
点 CSavepoinO 用 来 通知 系统 应 该 记 住 事务 当前 的 状态 ， 以 便当 之 后 发 
生 错 误 时 ， 事 务 能 回 到 保存 点 当时 的 状态 。 


对 于 扁平 的 事务 来 说 ， 其 隐 式 地 设置 了 一 个 保存 点 。 然 而 在 整个 事 
务 中 ， 只 有 这 一 个 保存 点 ， 因 此 ， 回 深 只 能 回 深 到 事务 开始 时 的 状态 。 
保存 点 用 SAVE WORK 函 数 来 建立 ， 通 知 系统 记录 当前 的 处 理 状态 。 当 
出 现 问题 时 ， 保 存 点 能 用 作 内 部 的 重启 动 点 ， 根 据 应 用 逻辑 ， 决 定 是 回 
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BEGIN WORK 
隐 含 SAVE WORK: 1 


Action 
Action 
SAVE WORK: 2 
Action 


SAVE WORK: 3 


Action 
Action 
Action 
SAVE WORK: 4 
Action 


ROLLBACK WORK: 2 





保存 点 2 覆盖 的 操作 















保存 点 5 覆盖 的 操作 









图 7-2 在 事务 中 使 用 保存 点 


图 7-2 显 示 了 如 何在 事务 中 使 用 保存 点 。 灰 色 背 景 部 分 的 操作 表示 
由 ROLLBACK WORK 而 导致 部 分 回 滚 ， 实 际 并 没有 执行 的 操作 。 当 用 
BEGIN WORK 开启 一 个 事务 时 ， 隐 式 地 包含 了 一 个 保存 点 ， 当 事务 通 
过 ROLLBACK WORK : 2 发 出 部 分 回 滚 命令 时 ， 事 务 回 滚 到 保存 点 2， 
接着 依次 执行 ， 并 再 次 执行 到 ROLLBACK WORK : 7， 直 到 最 后 的 
COMMIT ” WORK 操作 ， 这 时 表示 事务 结束 ， 除 灰色 阴影 部 分 的 操作 
外 ， 其 余 操作 都 已 经 执行 ， 并 且 提 交 。 


另 一 点 需要 注意 的 是 ， 保 存 点 在 事务 内 部 是 递增 的 ， 这 从 图 7-2 中 
也 能 看 出 。 有 人 可 能 会 想 ， 返 回 保存 点 2 以 后 ， 下 一 个 保存 点 可 以 为 3， 
因为 之 前 的 工作 都 终止 了 。 然 而 新 的 保存 点 编号 为 5， 这 意味 着 
ROLLBACK 不 影响 保存 点 的 计数 ， 并 且 单 调 递增 的 编号 能 保持 事务 执 
行 的 整个 历史 过 程 ， 包 括 在 执行 过 程 中 想法 的 改变 。 


此 外 ， 当 事务 通过 ROLLBACK WORK: 2 命令 发 出 部 分 回 滚 命令 
时 ， 要 记 住 事务 并 没有 完全 被 回 深 ， 只 是 回 滚 到 了 保存 点 2 而 已 。 这 代 
表 当 前 事务 还 是 活跃 的 ， 如 果 想 要 完全 回 滚 事务 ， 还 需要 再 执行 命令 
ROLLBACK WORK。 


链 事务 (Chained Transaction) 可 视 为 保存 点 模式 的 一 种 变种 。 带 
有 保存 点 的 扁平 事务 ， 当 发 生 系统 月 误 时 ， 所 有 的 保存 点 都 将 消失 ， 因 
为 其 保存 点 是 易 失 的 〈volatile) ， 而 非 持 久 的 〈persistent) 。 这 意味 着 
za 事务 需要 从 开始 处 重新 执行 ， 而 不 能 从 最 近 的 一 个 保存 
点 继续 执行 。 


链 事务 的 思想 是 : 在 提交 一 个 事务 时 ， 释 放 不 需要 的 数据 对 象 ， 将 
必要 的 处 理 上 下 文 隐 式 地 传 给 下 一 个 要 开始 的 事务 。 注 意 ， 所 交 事 务 操 
作 和 开始 下 一 个 事务 操作 将 合并 为 一 个 原子 操作 。 这 意味 着 下 一 个 事务 
将 看 到 上 一 个 事务 的 结果 ， 就 好 像 在 一 个 事务 中 进行 的 一 样 。 图 7-3 显 
示 了 链 事务 的 工作 方式 : 
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图 7-3 链 事务 的 开始 ， 第 一 个 事务 提交 触发 第 二 个 事务 的 开始 











链 事 务 与 带 有 保存 点 的 局 平 事务 不 同 的 是 ， 币 有 保存 点 的 局 平 事务 
能 回 深 到 任意 正确 的 保存 点 。 而 链 事务 中 的 回 深 仅 限于 当前 事务 ， 即 只 
能 恢复 到 最 近 一 个 的 保存 点 。 对 于 锁 的 处 理 ， 两 者 也 不 相同 。 链 事务 在 
执行 COMMIT 后 即 杰 放 了 当前 事务 所 持 有 的 锁 ， 而 带 有 保存 点 的 局 平 事 
务 不 影响 迄今 为 止 所 持 有 的 锁 。 


ix 424443 (Nested Transaction) 是 一 个 层次 结构 框架 。 由 一 个 顶层 
事务 (top-level transaction) 控制 着 各 个 层次 的 事务 。 顶 层 事 务 之 下 般 套 
的 事务 被 称 为 子 事务 (subtransaction) ， 其 控制 每 一 个 局 部 的 变换 。 扔 
套 事务 的 层次 结构 如 图 7-4 所 示 。 


COMMIT WORK 
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务 ， 也 可 以 是 局 平 事务 。 


2) 处 在 叶 节 点 的 事务 是 局 平 事务 。 但 是 每 个 子 事 务 从 根 到 叶 市 点 
的 距离 可 以 是 不 同 的 。 


3) 位 于 根 节点 的 事务 称 为 顶层 事务 ， 其 他 事务 称 为 子 事务 。 事 务 
的 前 驱 称 〈predecessor) 为 父 事务 (parent) ， 事 务 的 下 一 层 称 为 儿子 
事务 (child) 。 


4) 子 事务 既 可 以 提交 也 可 以 回 深 。 但 是 它 的 提交 操作 并 不 马上 生 
效 ， 除 非 其 父 事务 已 经 提交 。 因 此 可 以 推论 出 ， 任 何 子 事物 都 在 顶层 事 
务 提交 后 才 真 正 的 提交 。 


D 树 中 的 任意 一 个 事务 的 回 滚 会 引起 它 的 所 有 子 事务 一 同 回 滚 ， 
故 子 事 务 仅 保留 A、C、! 特 性 ， 不 具有 DD 的 特性 。 


在 Moss 的 理论 中 ， 实 际 的 工作 是 交 由 叶子 节点 来 完成 的 ， 即 只 有 叶 
子 节点 的 事务 才能 访问 数据 库 、 发 送 消息 、 获 取 其 他 类 型 的 资源 。 而 高 
层 的 事务 仅 负责 逻辑 控制 ， 决 定 何 时 调用 相关 的 子 事务 。 即 使 一 个 系统 
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大 的 灵活 性 。 例 如 在 完成 Tk3 这 事务 时 ， 可 以 回 深 到 保存 点 52 的 状态 。 
而 在 租 套 查询 的 层次 结构 中 ， 这 是 不 被 允许 的 。 


但 是 用 保存 点 技术 来 模拟 舱 套 事务 在 锁 的 持 有 方面 还 是 与 租 套 查询 
有 些 区 别 。 当 通过 保存 点 技术 来 模拟 舱 套 事务 时 ， 用 户 无 法 选择 哪些 锁 
需要 被 子 事务 继承 ， 哪 些 需 要 被 父 事 务 保 留 。 这 束 是 说 ， 无 论 有 多 少 个 
保存 点 ， 所 有 被 锁 住 的 对 象 都 可 以 被 得 到 和 访问 。 而 在 髋 套 查 询 中 ， 不 
同 的 子 事务 在 数据 库 对 象 上 持 有 的 锁 是 不 同 的 。 例 如 有 一 个 父 事务 P ， 
其 持 有 对 象 X 和 Y 的 排他 锁 ， 现 在 要 开始 一 个 调用 子 事务 P ,， 那 么 父 事 
务 P 可 以 不 传递 锁 ， 也 可 以 传递 所 有 的 锁 ， 也 可 以 只 传递 一 个 排他 锁 。 
如 果子 事务 P 中 还 要 持 有 对 象 Z 的 排他 锁 ， 那 么 通过 反 回 继承 Ccounter- 
inherited) ， 父 事务 P 将 持 有 3 个 对 象 X、Y、2Z 的 排他 锁 。 如 果 这 时 又 再 
次 调用 了 一 个 子 事务 P,， 那 么 它 可 以 选择 传递 那里 已 经 持 有 的 锁 。 

然而 ， 如 果 系 统 文 持 在 众 套 事务 中 并 行 地 执行 各 个 子 事务 ， 在 这 种 
情况 下 ， 采 用 保存 点 的 局 平 事务 来 模拟 骸 套 事务 就 不 切实 际 了 。 这 从 男 
mE 想 要 实现 事务 间 的 并 行 性 ， 需 要 真正 文 持 的 般 套 事 


分 布 式 事务 (Distributed Transactions) 通常 是 一 个 在 分 布 式 环境 下 
运行 的 局 平 事务 ， 因 此 需要 根据 数据 所 在 位 置 访问 网 络 中 的 不 同 节 点 。 


假设 一 个 用 户 在 ATM 机 进行 银行 的 转账 操作 ， 例 如 持 卡 人 从 招商 
银行 的 储蓄 卡 转账 10 000 元 到 工商 银行 的 储蓄 卡 。 在 这 种 情况 下 ， 可 以 
将 ATM 机 视 为 节点 A， 招 丙 银行 的 后 台数 据 库 视 为 节点 B， 工 商 银行 的 
后 台数 据 库 视 为 C， 这 个 转账 的 操作 可 分 解 为 以 下 的 步骤 : 
节点 A 及 出 转账 命令 。 
节点 B 执 行 储蓄 卡 中 的 余额 值 减 去 10 000. 
节点 C 执 行 储蓄 卡 中 的 余额 值 加 上 10 000. 


节点 A 通知 用 户 操 作 完 成 或 者 节点 A 通知 用 户 操 作 失 败 。 
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这 里 需要 使 用 分 布 式 事务 ， 因 为 节 扣 A 不 能 通过 调用 一 台数 据 库 就 
完成 任务 。 其 需要 访问 网 络 中 两 个 节点 的 数据 库 ， 而 在 每 个 节点 的 数据 
库 执行 的 事务 操作 又 都 是 局 平 的 。 对 于 分 布 式 事务 ， 其 同样 需要 满足 
ACID 特 性 ， 要 么 都 发 生 ， 要 么 部 失 效 。 对 于 上 述 的 例子 ， 如 果 2) 、 
3) 步 中 任何 一 个 操作 失败 ， 都 会 导致 整个 分 布 式 事务 回 深 。 辱 非 这 
样 ， 结 果 会 非常 可 怕 。 


对 于 InnoDB 存 储 引 擎 来 说 ， 其 支持 局 平 事务 、 带 有 保存 点 的 事 
、 链 事务 、 分 布 式 事务 。 对 于 岁 套 事务 ， 其 并 不 原生 支持 ， 因 此 ， 对 
并 行事 务 需 求 的 用 户 来 说 ，MySQL 数 据 库 或 mhnoDB 存 储 引 擎 就 显得 
能 为 力 了 。 然 而 用 户 仍 可 以 通过 带 有 保存 点 的 事务 来 模拟 串 行 的 租 套 
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7.2 事务 的 实现 


事务 隔离 性 由 第 6 章 讲述 的 锁 来 实现 。 原 子 性 、 一 致 性、 持久 性 通 
过 数据 库 的 redo log 和 undo log 来 完成 。redo log 称 为 重 做 日 志 ， 用 来 保证 
事务 的 原子 性 和 持久 性 。undo log 用 来 保证 事务 的 一 致 性 。 


有 的 DBA 或 许 会 认为 undo 是 redo 的 逆 过 程 ， 其 实 不 然 。redo 和 undo 
的 作用 都 可 以 视 为 是 一 种 恢复 操作 ，redo 恢 复 提 交 事 务 修改 的 页 操作 ， 
而 undo 回 深 行 记录 到 某 个 特定 版 本 。 因 此 两 者 记录 的 内 容 不 同 ，redo 通 
常 是 物理 日 志 ， 记 录 的 是 页 的 物理 修改 操作 。undo 是 逻辑 日 志 ， 根 据 每 
行 记 录 进 行 记录 。 











7.2.1 redo 
1. 基 本 概念 


重 做 日 志 用 来 实现 事务 的 持久 性 ， 即 事务 ACID 中 的 D。 其 由 两 部 分 
组 成 : 一 是 内 存 中 的 重 做 日 志 绥 冲 Credo log buffer) ， 其 是 易 失 的 ; 二 
是 重 做 日 志文 件 Credo log file) ， 其 是 持久 的 。 


InnoDB 是 事务 的 存储 引擎 ， 其 通过 Force Log at Commit 机 制 实现 事 
务 的 持久 性 ， 即 当 事 务 提交 (COMMIT) 时 ， 必 须 先 将 该 事务 的 所 有 日 
志 写 入 到 重 做 日 志文 件 进行 持久 化 ， 待 事务 的 COMMIT 操 作 完 成 才 算 完 
成 。 这 里 的 日 志 是 指 重 做 日 志 ， 在 InnoDB 存 储 引 擎 中 ， 由 两 部 分 组 
成 ， 即 redo log 和 undo log. redo log 用 来 保证 事务 的 持久 性 ，undo log 用 
来 帮助 事务 回 滚 及 MVCC 的 功能 。redo ”log 基 本 上 都 是 顺序 写 的 ， 在 数 
据 库 运 行 时 不 需要 对 redo log 的 文件 进行 读 取 操作 。 而 undo log 是 需要 进 
行 随机 读 写 的 。 


为 了 确保 每 次 日 志 都 写 入 重 做 日 志文 件 ， 在 每 次 将 重 做 日 志 绥 冲 写 
入 重 做 日 志文 件 后 ，InnoDB 存 储 引擎 都 需要 调用 一 次 fsync 操 作 。 由 于 
重 做 日 志文 件 打开 并 没有 使 用 O_DIRECT 选 项 ， 因 此 重 做 日 志 绥 冲 先 写 
入 文件 系统 缓存 。 为 了 确保 重 做 日 志 写 入 人 磁盘， 必须 进行 一 次 fsync 操 
作 。 由 于 fsync 的 效率 取决 于 人 磁盘 的 性 能 ， 因 此 磁盘 的 性 能 决定 了 事务 提 
交 的 性 能 ， 也 就 是 数据 库 的 性 能 。 














InnoDB 存 储 引 擎 允许 用 户 手 工 设 置 非 持 久 性 的 情况 发 生 ， 以 此 提 
高 数据 库 的 性 能 。 即 当 事 务 提交 时 ， 日 志 不 写 入 重 做 日 志文 件 ， 而 是 等 
待 一 个 时 间 周 期 后 再 执行 fsync 操 作 。 由 于 并 非 强 制 在 事务 提交 时 进行 一 
次 fsync 操 作 ， 显 然 这 可 以 显 埋 提高 数据 库 的 性 能 。 但 是 当 数 据 库 发 生 宕 
机 时 ， 由 于 部 分 日 志 未 刷新 到 磁盘 ， 因 此 会 丢失 最 后 一 段 时 间 的 事务 。 


参数 innodb_flush_log_at_trx_commit 用 来 控制 重 做 日 志 刷 新 到 磁盘 
的 策略 。 该 参数 的 默认 值 为 1， 表 示 事 务 提交 时 必须 调用 一 次 fsync 操 
作 。 还 可 以 设置 该 参数 的 值 为 0 和 2。0 表 示 事 务 提交 时 不 进行 写 入 重 做 
日 志 操 作 ， 这 个 操作 仅 在 master thread 中 完成 ， 而 在 master thread 中 每 1 
秒 会 进行 一 次 重 做 日 志文 件 的 fsync 操 作 。2 表 示 事 务 提交 时 将 重 做 日 志 
写 入 重 做 日 志文 件 ， 但 仅 写 入 文件 系统 的 缓存 中 ， 不 进行 fsync 操 作 。 在 
这 个 设置 下 ， 当 MySQL 数 据 库 发 生 宕 机 而 操作 系统 不 发 生 宕 机 时 ， 并 
不 会 导致 事务 的 丢失 。 而 当 操 作 系 统 宕 机 时 ， 重 启 数 据 库 后 会 丢失 未 从 
文件 系统 绥 存 刷新 到 重 做 日 志文 件 那 部 分 事务 。 


下 面 看 一 个 例子 ， 比 较 innodb_flush_log_at_trx_commit 对 事务 的 影 
啊 。 首 移 根 据 如 下 代码 创建 表 忆 和 存储 过 程 p_load: 














CREATE TABLE test load( 


, 
b CHAR(80) 

)ENGINE-INNODB; 

DELIMITER// 

CREATE PROCEDURE p load(count INT UNSIGNED) 
BEGIN 


DECLARE s INT UNSIGNED DEFAULT 1; 
DECLARE c CHAR(8@)DEFAULT REPEAT('a',80); 


WHIL t 

INSERT INTO test load SELECT NULL,c; 
MIT; 

SET s-s*1; 

END WHILE; 

END; 


// 
DELIMITER; 


存储 过 程 p_ load 的 作用 是 将 数据 不 断 地 插入 表 test load 中 ， 并 且 每 
插入 一 条 就 进行 一 次 显 式 的 COMMIT 操 作 。 在 默认 的 设置 下 ， 即 参数 
innodb_flush_log_at_trx_commit 为 1 的 情况 下 ，InnoDB 存 储 引 擎 会 将 重 做 
日 志 缓冲 中 的 日 志 写 入 文件 ， 并 调用 一 次 fync 操 作 。 如 果 执 行 命令 
CALL p load (500 000) ， 则 会 回 表 中 插入 50 万 行 的 记录 ， 并 执行 50 万 
次 的 fsync 操 作 。 先 看 在 默认 情况 插入 50 万 条 记录 所 需 的 时 间 下 : 








mysql>CALL p load(500000); 
Query OK,0 rows affected(1 min 53.11 sec) 





可 以 看 到 插入 50 万 条 记录 差不多 需要 2 分 钟 的 时 间 。 对 于 生产 环境 
的 用 户 来 说， 这 个 时 间 显 然 是 不 能 接受 的 。 而 造成 时 间 比 较 长 的 原因 融 
在 于 fync 操 作 所 需 的 时 间 。 接 着 来 看 将 参数 
innodb_flush_log_at_trx_commit 设 置 为 0 的 情况 : 
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Variable name nodb flush . lo og_at_trx_commit 


1 ec) 
mys sen D dos a (880000) ; 
Query 0 cted(13.90 sec) 


可 以 看 到 将 参数 innodb_flush_log_at_trx_commit 设 置 为 0 后 ， 插 入 50 
万 行 记录 的 时 间 缩 短 为 了 13.90 秒 ， 差 不 多 是 之 前 的 12%。 而 形成 这 个 现 
象 的 主要 原因 是 : 后 者 大 大 减少 了 fsync 的 次 数 ， 从 而 提高 了 数据 库 执 行 
的 性 能 。 表 7-1 显 示 了 在 参数 innodb_flush_log_at_trx_commit 的 不 同 设置 
下 ， 调 用 存储 过 程 p_ ljoad 插 入 50 万 行 记录 所 需 的 时 间 。 
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虽然 用 户 可 以 通过 设置 参数 innodb_flush_log_at_trx_commit 为 0 或 2 
来 提高 事务 提交 的 性 能 ， 但 是 需要 牢记 的 是 ， 这 种 设置 方法 丧失 了 事务 
的 ACID 特性 。 而 针对 上 述 存 储 过 程 ， 为 了 提高 事务 的 提交 性 能 ， 应 该 
在 将 50 万 行 记录 插入 表 后 进行 一 次 的 COMMIT 操 作 ， 而 不 是 在 每 插入 一 
条 记录 后 进行 一 次 COMMIT 操 作 。 这 样 做 的 好 处 是 还 可 以 使 事务 方法 在 
回 深 时 回 深 到 事务 最 开始 的 确定 状态 。 




















在 MySQL 数 据 库 中 还 有 一 种 二 进 制 日 志 Cbinlog) ， 其 用 来 进行 
POINT-IN-TIME (PIT) 的 恢复 及 主 从 复制 (Replication) 环境 的 建 
立 。 从 表面 上 看 其 和 重 做 日 志 非 常 相似 ， 都 是 记录 了 对 于 数据 库 操作 的 
日 志 。 然 而 ， 从 本 质 上 来 看 ， 两 者 有 着 非常 大 的 不 同 。 


首先 ， 重 做 日 志 是 在 InnoDB 存 储 引 擎 层 产 生 ， 而 三 进 制 日 志 是 在 
MySQL 数 据 库 的 上 层 产生 的 ， 并 且 二 进 制 日 志 不 仅仅 针对 于 InnoDB 存 
p Dresd EE 
二 进 制 日 志 。 


两 种 日 志 记 录 的 内 容 形 式 不 同 。MySQL 数 据 库 上 层 的 二 进 
制 日 xus 其 记录 的 是 对 应 的 SQL 语句 。 而 InnoDB 存 储 引 
擎 层面 的 重 做 日 志 是 物理 格式 日 志 ， 其 记录 的 是 对 于 每 个 页 的 修改 。 


此 外 ， 两 种 日 志 记 录 写 入 磁盘 的 时 间 点 不 同 ， 如 图 7-6 所 示 。 二 进 
制 日 志 只 在 事务 提交 完成 后 进行 一 次 写 入 。 而 InnoDB 存 储 引擎 的 重 做 
日 志 在 事务 进行 中 不 断 地 被 写 入 ， 这 表现 为 日 志 并 不 是 随 事 务 提交 的 顺 
序 进行 写 入 的 。 
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图 7-6 二 进 制 日 志 与 重 做 日 志 的 写 入 的 时 间 点 不 同 
从 图 7-6 中 可 以 看 到 ， 二 进 制 日 志 仅 在 事务 提交 时 记录 ， 并 且 对 于 











每 一 个 事务 ， 仅 包含 对 应 事务 的 一 个 日 志 。 而 对 于 InnoDB 存 储 引 擎 的 
重 做 日 志 ， 由 于 其 记录 的 是 物理 操作 日 志 ， 因 此 每 个 事务 对 应 多 个 日 志 
条 目 ， 并 且 事 务 的 重 做 日 志 写 入 是 并 发 的 ， 并 非 在 事务 提交 时 写 入 ， 故 
其 在 文件 中 记录 的 顺序 并 非 是 事务 开始 的 顺序 。*T1、*T2、*T3 表 示 的 
是 事务 提交 时 的 日 志 。 


2.log block 


在 mnoDB 存 储 引 擎 中 ， 重 做 日 志 都 是 以 512 字 节 进 行 存储 的 。 这 意 
味 着 重 做 日 志 绥 存 、 重 做 日 志文 件 都 是 以 块 (block) 的 方式 进行 保存 
的 ， 称 之 为 重 做 日 志 块 (redo log block) ， 每 块 的 大 小 为 512 字 节 。 


知 一 个 页 中 产生 的 重 做 日 志 数 量 大 于 512 字 节 ， 那 么 需要 分 割 为 多 
个 重 做 日 志 块 进行 存储 。 此 外 ， 由 于 重 做 日 志 块 的 大 小 和 磁盘 忆 区 大 小 
一 样 ， 都 是 512 字 节 ， 因 此 重 做 日 志 的 写 入 可 以 保证 原子 性 ， 不 需要 
doublewrite 技 术 。 


重 做 日 志 块 除了 日 志 本 里 之 外 ， 还 由 日 志 块 涉 (log block header) 
及 日 志 块 尾 Cog block tailer) 两 部 分 组 成 。 重 做 日 志 头 一 共 占 用 12 字 
节 ， 重 做 日 志 尾 占用 8 字 节 。 故 每 个 重 做 日 志 块 实际 可 以 存储 的 大 小 为 
492 字 节 〈512-12-8) 。 图 7-7 显 示 了 重 做 日 志 块 缓存 的 结构 。 
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图 7-7 重 做 日 志 块 缓存 的 结构 


图 7-7 显 示 了 重 做 日 志 绥 存 的 结构 ， 可 以 及 现 重 做 日 志 缓 存 由 每 个 
为 512 字 节 大 小 的 日 志 块 所 组 成 。 日 志 块 由 三 部 分 组 成 ， 依 次 为 日 志 块 
3k Clog block header) 、 日志 内 容 Clog body) 、 日 志 块 尾 Cog block 
tailer) 。 








log block header 由 4 部 分 组 成 ， 如 表 7-2 所 示 。 
71-2 og block header 
A SERT 


L0G BLOCK HOR NO | 
L0G BLOCK HDR DATA LEN 
L0G BLOCK FINT REC GROUP | 
L0G BLOCK CHECKPOINT NO | 


log buffer 是 由 log block 组 成 ， 在 内 部 log buffer 就 好 似 一 个 数组 ， 
此 LOG_BLOCK_HDR_NO 用 来 标记 这 个 数组 中 的 位 置 。 其 是 递增 并 且 
循环 使 用 的 ， 占 用 4 个 字 节 ， 但 是 由 于 第 一 位 用 来 判断 是 否 是 flush bit, 
所 以 最 大 的 值 为 2G。 


LOG_BLOCK_HDR_DATA_LEN 占 用 2 字 节 ， 表 示 log block 所 占用 
的 大 小 。 当 log block 被 写 满 时 ， 该 值 为 0x200， 表 示 使 用 全 部 log block 
间 ， 即 占用 512 字 节 。 


LOG_BLOCK_FIRST_REC_GROUP 占 用 2 个 字 节 ， 表 示 log block 中 
第 一 个 日 志 所 在 的 偏 移 量 。 如 果 该 值 的 大 小 和 








LOG_BLOCK_HDR_DATA_LEN 相 同 ， 则 表示 当前 log block 不 包含 新 的 
日 志 。 如 事务 T1 的 重 做 日 志 1 占用 762 字 节 ， 事 务 T2 的 重 做 日 志 占 用 100 

字 节 。 由 于 每 个 log block 实 际 只 能 保存 492 个 字 节 ， 因 此 其 在 log buffer 
中 的 情况 应 如 图 7-8 所 示 。 
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图 7-8 LOG BLOCK FIRST REC GROUP 的 例子 


从 图 7-8 中 可 以 观察 到 ， 由 于 事务 T1 的 重 做 日 志 占 用 792 字 节 ， 因 此 
要 占用 两 个 log block。 左 侧 的 log block 中 
LOG_BLOCK_FIRST_REC_GROUP 为 12， 即 log ”block 中 第 一 个 日 志 的 


开始 位 置 。 在 第 二 个 log block 中 ， 由 于 包含 了 之 前 事务 T1 的 重 做 日 志 ， 
事务 T2 的 日 志 才 是 log block 中 第 一 个 日 志 ， 因 此 该 log block 的 
LOG BLOCK_FIRST_REC_GROUP 为 282 (270+12) 。 





LOG_BLOCK_CHECKPOINT_NO 占 用 4 字 节 ， 表 示 该 log block 最 后 
被 写 入 时 的 检查 点 第 4 字 节 的 值 。 


log block ”tailer 只 由 1 个 部 分 组 成 (如 表 7-3 所 示 )， ， 且 其 值 和 
LOG_BLOCK_HDR_NO 相 同 ， 并 在 函数 log_block_init 中 被 初始 化 。 


1-4 log bock taler 3 
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3.log group 


log group 为 重 做 日 志 组 ， 其 中 有 多 个 重 做 日 志文 件 。 虽 然 源码 中 已 
支持 log group 的 镜像 功能 ， 但 是 在 ha_innobase.cc 文 件 中 禁止 了 该 功能 。 
因此 InnoDB 存 储 引 擎 实际 只 有 一 个 log group. 


log group 是 一 个 逻辑 上 的 概念 ， 并 没有 一 个 实际 存储 的 物理 文件 来 
表示 log group 信 息 。log group 由 多 个 重 做 日 志文 件 组 成 ， 每 个 log group 
中 的 日 志文 件 大 小 是 相同 的 ， 且 在 InnoDB 1.2 版 本 之 前 ， 重 做 日 志文 件 
的 总 大 小 要 小 于 4GB (不 能 等 于 4GB)。 从 InnoDB 1.2 版 本 开始 重 做 日 
志文 件 总 大 小 的 限制 提高 为 了 512GB。InnoSQL 版 本 的 InnoDB 存 储 引 擎 
在 1.1 版 本 就 支持 大 于 4GB 的 重 做 日 志 。 


重 做 日 志文 件 中 存储 的 就 是 之 前 在 log buffer 中 保存 的 log block, 
此 其 也 是 根据 块 的 方式 进行 物理 存储 的 管理 ， 每 个 块 的 大 小 与 log block 
一 样 ， 同 样 为 512 字 市 。 在 InnoDB 存 储 引 擎 运行 过 程 中 ，log buffer 根 据 





一 定 的 规则 将 内 存 中 的 log block 刷 新 到 磁盘 。 这 个 规则 具体 是 : 
口 事务 提交 时 
口 当 log buffer 中 有 一 半 的 内 存 空 间 已 经 被 使 用 时 
Alog checkpoint 时 


对 于 log block 的 写 入 追加 Cappend) 在 redo log file 的 最 后 部 分 ， 当 


一 个 redo log file 被 写 满 时 ， 会 接着 写 入 下 一 个 redo log file， 其 使 用 方式 
为 round-robin 。 


虽然 log block 总 是 在 redo log file 的 最 后 部 分 进行 号 入 ， 有 的 读者 可 
能 以 为 对 redo log file 的 写 入 都 是 顺序 的 。 其 实 不 然 ， 因 为 redo log | file 除 
了 保存 log buffer 刷 新 到 磁盘 的 log block， 还 保存 了 一 些 其 他 的 信息 ， 这 
些 信息 一 共 占 用 2KB 大 小 ， 即 每 个 redo log file 的 前 2KB 的 部 分 不 保志 log 
block 的 信息 。 对 于 log group 中 的 第 一 个 redo log file， 其 前 2KB 的 部 分 保 
存 4 个 512 字 节 大 小 的 块 ， 其 中 存放 的 内 容 如 表 7-4 所 示 。 
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需要 特别 注意 的 是 ， 上 述 信息 仅 在 每 个 log group 的 第 一 个 redo log 


file 中 进行 存储 。log group 中 的 其 余 redo log file 仅 保留 这 些 空间 ， 但 不 保 
存 上 述 信息 。 正 因为 保存 了 这 些 信 息 ， 就 意味 着 对 redo log file 的 写 入 并 
不 是 完全 顺序 的 。 因 为 其 除了 log block 的 写 入 操作 ， 还 需要 更 新 前 2KB 
部 分 的 信息 ， 这 些 信息 对 于 InnoDB 存 储 引 擎 的 恢复 操作 来 说 非常 关键 
IRSE, Mog group 与 redo log file 之 间 的 关系 如 图 7-9 所 示 。 
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图 7-9 log group 与 redo log file 之 间 的 关系 


在 log filer header 后 面 的 部 分 为 InnoDB 存 储 引 擎 保存 的 
checkpoint ÆR) 值 ， 其 设计 是 交替 写 入 ， 这 样 的 设计 避免 了 因 介 
质 失 败 而 导致 无 法 找到 可 用 的 checkpoint 的 情况 。 


4. 重 做 日 志 格 式 


不 同 的 数据 库 操作 会 有 对 应 的 重 做 日 志 格 式 。 此 外 ， 由 于 InnoDB 
存储 引擎 的 存储 管理 是 基于 页 的 ， 故 其 重 做 日 志 格 式 也 是 基于 页 的 。 虽 
SE 同 的 重 做 日 志 格 式 ， 但 是 它们 有 着 通用 的 头 部 格式 ， 如 图 7-10 

ZN o 











redo log type redo log body 


7-10 重 做 日 志 格 式 
通用 的 头 部 格式 由 以 下 3 部 分 组 成 : 
Dredo log type: 重 做 日 志 的 类 型 。 


Dispace: XT HIID. 


DQpage_no: 页 的 偏 移 量 


之 后 redo log body 的 部 分 ， 根 据 重 做 日 志 类 型 的 不 同 ， 会 有 不 同 的 
存储 内 容 ， 例 如 ， 对 于 页 上 记录 的 插入 和 删除 操作 ， 分 别 对 应 如 图 7-11 
所 示 的 格式 : 


MLOG_REC INSERT 


tbody 


一 一 = 
co 





MLOG REC DELETE 


7-11 插入 和 删除 的 重 做 日 志 格 式 


到 InnoDB1.2 版 本 时 ， 一 共有 51 种 重 做 日 志 类 型 。 随 着 功能 不 断 地 
增加 ， 相 信 会 加 入 越 来 越 多 的 重 做 日 志 类 型 。 


5.LSN 





LSN 是 Log Sequence Number 的 缩写 ， 其 代表 的 是 日 志 序 列 号 。 在 
InnoDB 存 储 引 擎 中 ，LSN 占 用 8 字 节 ， 并 且 单 调 递 增 。LSN 表 示 的 含义 
有 : 


口 重 做 日 志 写 入 的 总 量 

口 checkpoint 的 位 置 

口 页 的 版 本 

LSN 表 示 事 务 写 入 重 做 日 志 的 字 节 的 总 量 。 例 如 当前 重 做 日 志 的 
LSN 为 1 000， 有 一 个 事务 T1 写 入 了 100 字 节 的 重 做 日 志 ， 那 么 LSN 就 变 


为 了 1100， 若 又 有 事务 T2 写 入 了 200 字 节 的 重 做 日 志 ， ie 
了 1300。 可 见 LSN 记 录 的 是 重 做 日 志 的 总 量 ， 其 单位 为 字 











LSN 不 仅 记录 在 重 做 日 志 中 ， 还 存在 于 每 个 页 中 。 在 每 个 页 的 头 
部 ， 有 一 个 值 FIL_PAGE_LSN， 记 录 了 该 页 的 LSN。 在 页 中 ，LSN 表 示 
该 页 最 后 刷新 时 LSN 的 大 小 。 因 为 重 做 日 志 记 录 的 是 每 个 页 的 日 志 ， 因 
页 中 的 LSN 用 来 判断 页 是 否 需 要 进行 恢复 操作 。 例 如 ， 页 P1 的 LSN 为 
10 ”000， 而 数据 库 启 动 时 ，InnoDB 检 测 到 写 入 重 做 日 ; 1 
000， 并 且 该 事务 已 经 提交 ， 那 么 数据 库 需 要 进行 恢复 操作 ， 将 重 做 日 
志 应 用 到 P1 页 中 。 同 样 的 ， 对 于 重 做 日 志 中 LSN 小 于 P1 页 的 LSN， 不 需 
要 进行 重 做 ， 因 为 P1 页 中 的 LSN 表 示 页 已 经 被 刷新 到 该 位 置 。 


用 户 可 以 通过 命令 SHOW ENGINE INNODB STATUS 查 看 LSN 的 情 




















Wu: 





mysql>SHOW ENGINE INNODB STATUS\G; 
LOG 

Log sequence number 11 3047174608 
Log flushed up to 11 3047174608 
Last checkpoint at 11 3047174608 


© pending log writes,0 pending chkp writes 
142 log i/o's done,0.00 log i/o's/second 


1 row in set(0.00 sec) 





Log sequence number 表 示 当 前 的 LSN，Log flushed up to 表示 刷新 到 
重 做 日 志文 件 的 LSN，Last checkpoint at 表示 刷新 到 磁盘 的 LSN。 


虽然 在 上 面 的 例子 中 ，Log sequence number 和 Log flushed up to 的 值 
是 相同 的 ， 但 是 在 实际 生产 环境 中 ， 该 值 有 可 能 是 不 同 的 。 因 为 在 一 个 
事务 中 从 日 志 组 冲刷 新 到 重 做 日 志文 件 并 不 只 是 在 事务 提交 时 发 和 后， 每 
秒 都 会 有 从 日 志 绥 冲刷 新 到 重 做 日 志文 件 的 动作 。 下 面 是 在 生产 环境 下 
重 做 日 志 的 信息 的 示例 。 











We engine innodb status\G; 
LOG 


Log seque mber 203318213447 
Log flushe B üp 6 203318213326 
Last checkpoint at 203252831194 
1 pending log wei ites,0 pending chkp writes 
103447 log i/o s done, 7.00 log i/o's/second 


1 row in set(0.00 sec) 





可 以 看 到 ， 在 生产 环境 下 Log sequence number. Log flushed up to. 
Last checkpoint at 三 个 值 可 能 是 不 同 的 。 


6. 恢 复 





InnoDB 存 储 引 擎 在 启动 时 不 管 上 次 数据 库 运 行 时 是 否 正常 关闭 ， 
都 会 尝试 进行 恢复 操作 。 因 为 重 做 日 志 记 录 的 是 物理 日 志 ， 因 此 恢复 的 
速度 比 逻 辑 日 志 ， 如 二 进 制 日 志 ， 要 快 很 多 。 与 此 同时 ，InnoDB 存 储 
引擎 自身 也 对 恢复 进行 了 一 定 程 度 的 优化 ， 如 顺序 读 取 及 并 行 应 用 重 做 
日 志 ， 这 样 可 以 进一步 地 提高 数据 库 恢 复 的 速度 。 


由 于 checkpoint 表 示 已 经 刷新 到 磁盘 页 上 的 LSN， 因 此 在 恢复 过 程 
中 仅 需 恢复 checkpoint 开 始 的 日 志 部 分 。 对 于 图 7-12 中 的 例子 ， 当 数据 
库 在 checkpoint 的 LSN 为 10 000 时 发 生 宕 机 ， 恢 复 操作 仅 恢复 LSN 10 000 
~13 000 范 围 内 的 日 志 。 











redo log LSN: 10000 LSN: 13000 





Buffer Pool 


checkpoint LSN; 10 000 





Disk Disk Disk 


图 732 恢复 的 例子 
InnoDB 存 储 引 擎 的 重 做 日 志 是 物理 日 志 ， 因 此 其 恢复 速度 较 之 二 








进 制 日 志 恢 复 快 得 多 。 例 如 对 于 INSERT 操 作 ， 其 记录 的 是 每 个 页 上 的 
变化 。 对 于 下 面 的 表 : 


BLE t(a INT,b INT,PRIMARY KEY(a),KEY(b)); 


THATTSQLIB S: 





INSERT INTO t SELECT 1,2; 


jeg UT BERT TRAD GR ITI E, SHER 


page(2,3),offset 32,value 1,24 RERS] 
page(2,4),offset 64,value 2# 辅 助 索引 


可 以 看 到 记录 的 是 页 的 物理 修改 操作 ， 大 插入 涉及 B+ 树 的 split， 可 
能 会 有 更 多 的 页 需要 记录 日 志 。 此 外 ， 由 于 重 做 日 志 是 物理 日 志 ， 因 此 
其 是 早 等 的 。 需 等 的 概念 如 下 : 








SSF x)) =f (x) 


有 的 DBA 或 开发 人 员 错 误 地 认为 只 要 将 二 进 制 日 志 的 格式 设置 为 
ROW， 那 么 二 进 制 日 志 也 是 窜 等 的 。 这 显然 是 错误 的 ， 举 个 简单 的 例 
子 ，INSERT 操 作 在 二 进 制 日 志 中 就 不 是 军 等 的 ， 重 复 执 行 可 能 会 插入 
多 条 重复 的 记录 。 而 上 述 INSERT 操 作 的 重 做 日 志 是 朝 等 的 。 











7.2.2 undo 
1. 基 本 概念 


重 做 日 志 记 录 了 事务 的 行为 ， 可 以 很 好 地 通过 其 对 页 进行 “ 重 做 ” 操 
作 。 但 是 事务 有 时 还 需要 进行 回 滚 操作 ， 这 时 就 需要 undo。 因 此 在 对 数 
据 库 进行 修改 时 ，InnoDB 存 储 引 擎 不 但 会 产生 redo， 还 会 产生 一 定量 的 
undo。 这 样 如 果 用 户 执 行 的 事务 或 语句 由 于 某 种 原因 失败 了 ， 又 或 者 用 
户 用 一 条 ROLLBACK 语 句 请 求 回 深 ， 就 可 以 利用 这 些 undo 信 息 将 数据 
回 深 到 修改 之 前 的 样子 。 


redo 存 放 在 重 做 日 志文 件 中 ， 与 redo 不 同 ，undo 存 放 在 数据 库 内 部 
的 一 个 特殊 段 〈segment) 中 ， 这 个 段 称 为 undo 段 (undo segment) 。 
undo 段 位 于 共享 表 空 间 内 。 可 以 通过 py_innodb_page_info.py 工 具 来 查看 
当前 共享 表 空 间 中 undo 的 数量 。 如 下 代码 显示 当前 的 共享 表 空间 ibdatal 
内 有 2222 个 undo 页 。 


























ot@xen-server~]#python py innodb page info.py/usr/local/mysql/data/ibdatai 
r of page:46208: 


E 
Oo o 
see 


m Page:1 
ed Page:4579 


e mumcmagognunc-J--o- 
t| [p.253 DOO 





用 户 通常 对 undo 有 这 样 的 误解 : undo 用 于 将 数据 库 物 理 地 恢复 到 执 
行 语句 或 事务 之 前 的 样子 一 一 但 事实 并 非 如 此 。undo 是 逻辑 日 志 ， 因 此 
只 是 将 数据 库 人 逻辑 地 恢复 到 原来 的 样子 。 所 有 修改 都 被 逻辑 地 取消 了 ， 
但 是 数据 结构 和 页 本 身 在 回访 之 后 可 能 大 不 相同 。 这 是 因为 在 多 用 户 并 
发 系统 中 ， 可 能 会 有 数 十 、 数 百 甚 至 数 干 个 并 发 事务 。 数 据 库 的 主要 任 
务 就 是 协调 对 数据 记录 的 并 发 访问 。 比 如 ， 一 个 事务 在 修改 当前 一 个 页 
中 茶几 条 记录 ， 同 时 还 有 别 的 事务 在 对 同一 个 页 中 夯 几 条 记录 进行 修 
改 。 因 此 ， 不 能 将 一 个 页 回 深 到 事务 开始 的 样子 ， 因 为 这 样 会 影响 其 他 
事务 正在 进行 的 工作 。 


例如 ， 用 户 执 行 了 一 个 INSERT 10W 条 记录 的 事务 ， 这 个 事务 会 导 
致 分 配 一 个 新 的 段 ， 即 表 空 间 会 增 大 。 在 用 户 执行 ROLLBACK 时 ， 会 
将 插入 的 事务 进行 回 滚 ， 但 是 表 空 间 的 大 小 并 不 会 因此 而 收缩 。 因 此 ， 




















当 InnoDB 存 储 引 擎 回 滚 时 ， 它 实际 上 做 的 是 与 先前 相反 的 工作 。 对 于 
每 个 INSERT，InnoDB 存 储 引擎 会 完成 一 个 DELETE; 对 于 每 个 
DELETE，InnoDB 存 储 引 擎 会 执行 一 个 INSERT; 对 于 每 个 UPDATE， 
InnoDB 存 储 引 擎 会 执行 一 个 相反 的 UPDATE， 将 修改 前 的 行 放 回去 。 


除了 回 深 操 作 ，undo 的 男 一 个 作用 是 MVCC， 即 在 InnoDB 存 储 引 苟 
中 MVCC 的 实现 是 通过 undo 来 完成 。 当 用 户 读 取 一 行 记录 时 ， 硝 该 记录 
已 经 被 其 他 事务 占用 ， 当 前 事务 可 以 通过 undo 读 取 之 前 的 行 版 本 信息 ， 
以 此 实现 非 锁 定 读 取 。 


最 后 也 是 最 为 重要 的 一 点 是 ，undo log 会 产生 redo log， 也 就 是 undo 
log 的 产生 会 伴随 着 redo log 的 产生 ， 这 是 因为 undo log 也 需要 持久 性 的 保 
Pa 


2.undo 存 储 管 理 


InnoDB 存 储 引 擎 对 undo 的 管理 同样 采用 段 的 方式 。 但 是 这 个 段 和 
之 前 介绍 的 段 有 所 不 同 。 首 先 PnnoDB 存 储 引 擎 有 rollback segment， 每 个 
回 滚 段 种 记录 了 1024 个 undo log segment， 而 在 每 个 undo log segment 段 
中 进行 Indo 页 的 申请 。 共 享 表 空 间 偏 移 量 为 5 的 页 (0，5) 记录 了 所 有 
rollback segment header 所 在 的 页 ， 这 个 页 的 类 型 为 
FIL PAGE TYPE SYS. 


在 InnoDB1.1 版 本 之 前 (不 包括 1.1 版 本 ) ， 只 有 一 个 rollback 
segment， 因 此 文 持 同 时 在 线 的 事务 限制 为 1024。 虽 然 对 绝 大 多 数 的 应 
用 来 说 都 已 经 够 用 ， 但 不 管 怎 么 说 这 是 一 个 瓶颈 。 从 1.1 版 本 开始 
InnoDB 文 持 最 大 128 个 rollback segment， 故 其 支持 同时 在 线 的 事务 限制 
提高 到 了 128*1024。 























虽然 InnoDB1.1 版 本 支持 了 128 个 rollback segment， 但 是 这 些 rollback 
segment 都 存储 于 共享 表 空间 中 。 从 InnoDB1.2 版 本 开始 ， 可 通过 参数 对 
rollback segment 做 进一步 的 设置 。 这 些 参数 包括 : 
Llinnodb undo directory 


Llinnodb undo logs 


Llinnodb undo tablespaces 


ZJinnodb undo directory Hd Fv Eirollback ” segment 文件 所 在 的 路 
径 。 这 意味 着 rollback segment 可 以 存放 在 共享 表 空 间 以 外 的 位 置 ， 即 可 
以 设置 为 独立 表 空 间 。 该 参数 的 默认 值 为 “.”， 表 示 当 前 InnoDB 存 储 引 
擎 的 目录 。 


参数 innodb_undo_logs 用 来 设置 rollback segment 的 个 数 ， 默 认 值 为 
128。 在 InnoDB1.2 版 本 中 ， 该 参数 用 来 蔡 换 之 前 版 本 的 参数 


innodb rollback segments. 








参数 innodb_undo_tablespaces 用 来 设置 构成 rollback segment X44 HJ Zt 
量 ， 这 样 rollback segment 可 以 较为 平均 地 分 布 在 多 个 文件 中 。 设 置 该 参 
数 后 ， 会 在 路 径 innodb_undo_directory 看 到 undo 为 前 绥 的 文件 ， 该 文件 
就 代表 rollback Segment 文件。 图 7-13 的 示例 显示 了 由 3 个 文件 组 成 的 


rollback segment. 





myspl> SHOW VARIABLES LIKE 'innodb undot'; 
和 + 
| Variable name | Value 
-= jeune t 
| innodb undo directory | ， 

| innodb undo logs | 128 





| innodb undo tablespaces] 3 
He jene + 
3 rows in set (0.00 sec) 


mysql» SHOW VARIABLES LIKE 'datadir'; 
jeu | + 
| Variable name| Value 
feu te + 
| datadir | /Vsers/david/mysql data/data/ 
jeu | + 





1 row in set (0.00 sec) 


mysql» system ls -lh/Users/david/mysql data/data/undo* 

-DW-1W---- 1 david staff — 10M 11 22 16:55/Users/david/mysq] data/data/undo001 
-DW-rw---- 1 david staff — 104 11 22 16:51/Users/david/mysql data/data/undo002 
-DW-1W---- 1 david staff — 10M 11 22 16:51/Users/david/mysql_ data/data/undo003 








图 7-313 由 3 个 文件 组 成 的 rollback segment 
需要 特别 注意 的 是 ， 事 务 在 undo log segment 分 配 页 并 写 入 undo log 
的 这 个 过 程 同样 需要 写 入 重 做 日 志 。 当 事务 提交 时 ，InnoDB 存 储 引擎 
会 做 以 下 两 件 事情 : 
口 将 undo log 放 入 列表 中 ， 以 供 之 后 的 purge 操 作 


口 判断 undo log 所 在 的 页 是 否 可 以 重用 ， 厦 可 以 分 配给 下 个 事务 使 





用 


事务 提交 后 并 不 能 马上 删除 undo log 及 undo log 所 在 的 页 。 这 是 因为 
可 能 还 有 其 他 事务 需要 通过 undo log 来 得 到 行 记录 之 前 的 版 本 。 故 事务 
提交 时 将 undo log 放 入 一 个 链表 中 ， 是 否 可 以 最 终 删 除 undo log 及 undo 
log 所 在 页 由 purge 线 程 来 判断 。 


此 外 ， 车 为 每 一 个 事务 分 配 一 个 单独 的 undo 页 会 非常 浪费 存储 空 
间 ， 特 别 是 对 于 OLTP 的 应 用 类 型 。 因 为 在 事务 提交 时 ， 可 能 并 不 能 马 
上 释放 页 。 假 设 某 应 用 的 删除 和 更 新 操作 的 TPS Ctransaction per 
second) 为 1000， 为 每 个 事务 分 配 一 个 undo 页 ， 那 么 一 分 钟 就 需要 
1000*60 个 页 ， 大 约 需 要 的 存储 空间 为 1GB。 帮 每 秒 的 purge 页 的 数量 为 
20， 这 样 的 设计 对 磁盘 空间 有 着 相当 高 的 要 求 。 因 此 ， 在 InnoDB 和 存储 
引擎 的 设计 中 对 undo 页 可 以 进行 重用 。 县 体 来 说 ， 当 事务 提交 时 ， 首 先 
将 undo log 放 入 链表 中 ， 然 后 判断 undo 页 的 使 用 空间 是 否 小 于 3/4， 若 是 
则 表示 该 ndo 页 可 以 被 重用 ， 之 后 新 的 undo log 记 录 在 当前 undo log 的 后 
面 。 由 于 存放 undo log 的 列表 是 以 记录 进行 组 织 的 ， 而 undo 页 可 能 存放 
着 不 同事 务 的 undo log， 因 此 purge 操 作 需 要 涉及 磁盘 的 离散 读 取 操作 ， 
是 一 个 比较 缓慢 的 过 程 。 


可 以 通过 命令 SHOW ENGINE INNODB STATUS 来 查看 链表 中 undo 
log 的 数量 ， Till: 




















mysql- SHOW ENGINE INNODB STATUS\G; 
FOI ICICI ICICI I I I Kk ea PLOW I IOC II ICICI I I I I I 


[9] 
or trx's n:o«2C03 undo n:0<0 
12 


Hi 

LIST OF TRANSACTIONS FOR EACH SESSION: 

---TRANSACTION 0,not started 

MySQL thread id 1,0S thread handle 0x1500f1000,query id 4 localhost root 
ine innodb status 


History list length 就 代表 了 undo log 的 数量 ， 这 里 为 12。purge 操 作 会 
减少 该 值 。 然 而 由 于 undo ”log 所 在 的 页 可 以 被 重用 ， 因 此 即使 操作 发 
^E, History list length 的 值 也 可 以 不 为 0。 

3.undo log 格 式 

在 InnoDB 存 储 引 擎 中 ，undo log 分 为 : 

Dinsert undo log 


update undo log 


insert undo log 是 指 在 insert 操 作 中 产生 的 undo log。 因 为 insert 操 作 的 
记录 ， 只 对 事务 本 身 可 见 ， 对 其 他 事务 不 可 见 《〈 这 是 事务 隅 离 性 的 要 
求 ) ， 故 该 ndo ”log 可 以 在 事务 提交 后 直接 删除 。 不 需要 进行 purge 操 
作 。insert undo log 的 格式 如 图 7-14 所 示 。 














insert undo log record 





图 7-14 insert undo log 的 格式 


图 7-14 显 示 了 insert undo log 的 格式 ， 其 中 * 表 示 对 存储 的 字段 进行 
了 压缩 。insert undo log 开 始 的 前 两 个 字 节 next 记 录 的 是 下 一 个 undo log 
的 位 置 ， 通 过 该 next 的 字 节 可 以 知道 一 个 undo ”log 所 占 的 空间 字 节 数 。 
类 似 地 ， 尾 部 的 两 个 字 节 记录 的 是 undo log 的 开始 位 置 。type_cmpl 占 用 
-个 字 节 ， 记 录 的 是 undo 的 类 型 ， 对 于 insert undo log， 该 值 总 是 为 11。 
undo_no 记 录 事 务 的 ID，table_ id 记录 undo ”log 所 对 应 的 表 对 象 。 这 两 个 
值 都 是 在 压缩 后 保存 的 。 接 着 的 部 分 记录 了 所 有 主键 的 列 和 值 。 在 进行 
rollback 操 作 时 ， 根 据 这 些 值 可 以 定位 到 具体 的 记录 ， 然 后 进行 删除 即 
Hf. 


update undo log 记 录 的 是 对 delete 和 update 操 作 产 生 的 undo log. iZ 
undo ”log 可 能 需要 提供 MVCC 机 制 ， 因 此 不 能 在 事务 提交 时 就 进行 市 
除 。 提 交 时 放 入 undo log 链表 ， 等 待 purge 线 程 进行 最 后 的 删除 。update 
undo log 的 结构 如 图 7-15 所 示 。 











update undo log record 


*DATA. ROLL PTR 


n unique index 





update vector 


1d 
| "*50s1 7 *lenl i u. old. coll ! 








fe 一 一 
| @pos2.{ *"Ilen2 i u old colz ! 
1 I A. I 
b ua RT E 
Gm ww.a © js. 1 ww UE e te 
上 一 一 一 一 一 三 一 一 一 一 一 -一 一 一 一 一 一 一 -i 
| *posN | *lenN ' u. old. coIN | 
RSS ESS 7 
n bytes below i 
| 1 | 
| eee: $ "peur | coll 
ELLAS See ee Pe ee 
r- > i 
| "ok ; len i col2 ‘ 
和 六 和 end 
NEC ART -NS A I 
1 1 


图 7-15 update undo log 格 式 


update undo log 相 对 于 之 前 介绍 的 insert undo log， 记 录 的 内 容 更 
多 ， 所 需 占 用 的 空间 也 更 大 。next、start、undo_no、table_id 与 之 前 介绍 
的 insert undo log 部 分 相同 。 这 里 的 type_cmpl， 由 于 update undo log% 5 
还 有 分 类 ， 故 其 可 能 的 值 如 下 : 


D12 TRX_UNDO_UPD_ EXIST_REC 更 新 non-delete-mark 的 记录 

口 13 TRX UNDO UPD DEL _REC 将 delete 的 记录 标记 为 not delete 

口 14TRX_UNDO_DEL MARK_REC 将 记录 标记 为 delete 

接着 的 部 分 记录 update_vector 信 息 ，update_vector 表 示 update 操 作 导 
致 发 后 改变 的 列 。 每 个 修改 的 列 信息 都 要 记录 的 undo log. FAR 
的 undo log 类 型 ， 可 能 还 需要 记录 对 索引 列 所 做 的 修改 。 

4. 查 看 undo 信 A 

Oracle 和 Microsoft SQL Server 数 据 库 都 由 内 部 的 数据 字典 来 观察 当 
前 undo 的 信息 ，InnoDB 存 储 引 擎 在 这 方面 做 得 还 不 够 ，DBA 只 能 通过 


原理 和 经 验 来 进行 判断 。InnoSQL 对 information_schema 进 行 了 扩展 ， 添 
加 了 两 张 数据 字典 表 ， 这 样 用 户 可 以 非常 方便 和 快捷 地 查看 undo 的 信 





首先 增加 的 数据 字 — 典 表 为 
INNODB TRX ROLLBACK SEGMENT. MEX, KAŽE ZAK 
用 来 查看 rollback segment， 其 表 结 构 如 图 7-16 所 示 。 


mysql> DESC INNODB TRE ROLLBACK SEGMENT; 


Segment 1d 


space 











page no 





























last page no igint 












































last offset ligint 








last trx no | varchar (18) 





update undo list | bigi 





te undo cached | bigint 





rt undo list | big 






























































cached | big] 











10 rows in set (0,00 sec) 





图 7-16 INNODB TRX ROLLBACK SEGMENTIS 445 #4 


例如 ， 可 以 通过 如 下 的 命令 来 得 看 rollback segment 所 在 的 页 : 





mysql>SELECT segment id,space, MEN no 
- >FROM oT TRX | ROLLBACK . SEGMENT 


ER CEET E 


A E Ene 中 
1919161 

11191451 

12191461 


128 rows in set(0.00 sec) 








另 一 张 数据 字典 表 为 INNODB_TRX_UNDO， 用 来 记录 事务 对 应 的 
undo log， 方 便 DBA 和 开发 人 员 详 细 了 解 每 个 事务 产生 的 undo 量 。 下 面 
首先 根据 如 下 代码 创建 测试 

to 








PNE TABLE t( 
INT, 


b VARCHAR(32), 
PRIMARY KEY(a), 


(b) 
)ENGINE-InnoDB; 








接着 插入 一 条 记录 ， 并 尝试 通过 INNODB_TRX_UNDO 观 察 该 事务 
的 undo log 的 情况 : 





mysql>TBEGIN; 

Query OK,0 rows affected(0.00 sec) 

mysql>INSERT INTO t SELECT 1,'1'; 

Query OK,1 row affected(0.00 sec) 

Records:1 Duplicates:0 Warnings:O 

mysql>SELECT*FROM information schema.INNODB TRX UNDO'G; 
ORO GIOI GIO] | ppt eer 
trx id:3001 

rseg id:2 

undo. rec no:0 

undo rec type:TRX UNDO INSERT REC 

size:12 

space:0 

page no:334 

offset:272 

1 row in set(0.00 sec) 





通过 数据 字典 表 可 以 看 到 ， 事 务 ID 为 3001，rollback segment 的 ID 为 
2， 因 为 是 该 条 事务 的 第 一 个 操作 ， 故 undo_rec_no 为 0。 之 后 可 以 看 到 
插入 的 类 型 为 TRX_UNDO_INSERT_REC， 表 示 是 insert undo log. size 
表示 undo log 的 大 小 ， 占 用 12 字 节 。 最 后 的 space、page_no、offset 表 示 
undo log 开始 的 位 置 。 打 开 文件 ibdatal1， 定 位 到 页 (334，272) ， 并 读 
取 12 字 节 ， 可 得 到 如 下 内 容 : 








01 1c Ob 00 16 04 80 00 00 01 01 10 





上 述 融 是 undo _ log 实际 的 内 容 ， 根 据 上 一 小 节 对 undo log 格 式 的 介 
绍 ， 可 以 整理 得 到 ; 





01 1c# 下 一 个 undo 10g 的 位 置 272+12=0x011ic 
Ob#undo 1og 的 类 型 ，TRX_UNDO_INSERT_REC 为 11 
Oo#undo 1og 的 记录 ， 等 同 于 undo_rec_no 
16# 表 的 ID 

94# 主 键 的 长 度 

80 00 00 01# 主 键 的 内 容 

01 10#undo 1og 开 始 的 偏 移 量 ，272=0x0110 





此 外 ， 由 于 知道 该 ndo log 所 在 的 rollback segment 的 ID 为 2， 用 户 还 
可 以 通过 数据 字典 表 INNODB _TRX_ ROLLBACK. SEGMENT £r £4 
前 rollback segment 的 信息 ， 如 : 





mysql>SELECT segment id,insert undo list,insert undo cached 
->FROM information schema.INNODB TRX ROLLBACK SEGMENT 
-二 WHERE segment id-2*6; 


segment id:2 
insert undo list:1 
insert undo cached:6 
1 row in set(0.00 sec) 





可 以 看 到 insert_undo_jlist 为 1。 若 这 时 进行 事务 的 COMMIT 操 作 ， 再 
查看 该 数据 字典 表 : 





mysql>COMMIT; 

Query OK,0 rows affected(0.00 sec) 

mysql>SELECT segment id,insert undo list,insert undo cached 
->FROM information schema.INNODB TRX ROLLBACK SEGMENT 

-二 WHERE segment id-2^56; 


segment id:2 
insert undo list:0 
insert undo cached:1i 
1 row in set(0.00 sec) 





可 以 发 现 ，insert_undo_list 变 为 0， 而 insert_undo_cached 增 加 为 1。 
这 就 是 前 面 所 介绍 的 undo 页 重用 。 下 次 再 有 事务 需要 向 该 rollback 
segment 申 请 undo 页 时 ， 可 以 直接 使 用 该 页 。 


接着 再 来 观察 delete 操 作 产生 的 undo log。 进 行 如 下 操作 : 











mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 

mysql>DELETE FROM t WHERE a=1; 

Query OK,1 row affected(0.00 sec) 

Records:1 Duplicates:0 Warnings:O 

mysql>SELECT*FROM information schema.INNODB TRX UNDO'G; 


trx id:3201 

rseg id:2 

undo. rec no:0 

undo rec type:TRX UNDO DEL MARK REC 
size:37 

space:0 

page no:326 


offset:620 
1 row in set(0.00 sec) 








用 上 述 同 样 的 方法 定位 到 页 326， 偶 移 量 为 620 的 位 置 ， 得 到 如 下 结 
果 : 





0518260 00 00 00 00 00 OO OO 00 OO 0O OO OO 02 91 Oe 00 
0518270 16 00 00 00 00 30 O1 eO 82 00 00 01 4e 01 10 04 
0518280 80 00 00 01 00 Ob 00 04 80 00 00 O1 03 01 31 02 
0518290 6c 00 00 00 00 00 00 00 OO 00 OO OO 00 OO 00 00 





接着 开始 整理 : 





02 91# 下 一 个 undo 1og 开 始 位 置 的 偏 移 量 
ge#undo 1og 类 型 ，TRX_UNDO_DEL_MARK_REC 为 14 
900#undo no 

16#table id 

900#info bits 

00 00 00 30 01 eg#rec 事 务 id 

82 00 00 01 4e 01 10#rec 回 深 指 针 
044 EKE 

80 00 00 01# 主 键 值 

00 Qb# 之 后 部 分 的 长 度 

99# 列 的 位 置 

94# 列 的 长 度 

80 00 00 01# 列 的 值 

93# 列 的 位 置 ， 前 699 一 92 为 系统 列 
91# 列 的 长 度 

31# 列 b， 插 入 的 字符 串 !1' 的 十 六 进 制 

02 6c# 开 始 位 置 的 偏 移 量 








观察 rollback segment 信 息 ， 可 以 看 到 : 





mysql>SELECT segment id,update undo list,update undo cached 
->FROM information schema.INNODB TRX ROLLBACK SEGMENT 

-二 WHERE segment id-2*6; 
JOOOOOOOOOOOOOOODOOOOOOOOOR] | pj FICCI II ICICI III III II I Ie 
segment_id:2 

update_undo_list:1 

update_undo_cached:0 

1 row in set(0.00 sec) 





同样 的 ， 在 事务 提交 后 ，undo 页 会 放 入 cache 列 表 以 供 下 次 重用 : 





mysql>COMMIT; 

Query OK,0 rows affected(0.00 sec) 

mysql>SELECT segment id,update undo list,update undo cached 
->FROM information schema.INNODB TRX ROLLBACK SEGMENT 

-二 WHERE segment id-2*6; 
JOOOOGOOOOOOOOOOOLDOO IOOOOOOR] I pj FICCI III ICICI III III III Ie 
segment_id:2 

update_undo_list:0 

update_undo_cached:1 

1 row in set(0.00 sec) 








通过 上 面 的 例子 可 以 看 到 ，delete 操 作 并 不 直接 删除 记录 ， 而 只 是 
将 记录 标记 为 已 删除 ， 也 就 是 将 记录 的 delete_ flag 设置 为 1。 而 记录 最 终 
的 删除 是 在 purge 操 作 中 完成 的 。 





最 后 来 看 update 操 作 产生 的 undo log 情 况 。 首 先 再 次 插入 记录 
(1, 10 ， 然 后 进行 update 操 作 ， 同 时 通过 数据 字典 表 
INNODB_TRX_UNDO 观 察 undo log 的 情况 : 








mysql>INSERT INTO t SELECT 1,'1'; 

mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 

mysql>UPDATE t SET b='2'WHERE a=1; 

Query OK,1 row affected(0.00 sec) 

Rows matched:1 Changed:1 Warnings:0 

mysql>SELECT*FROM information schema.INNODB TRX UNDO'G; 
JOOOOEOOOOOOOAOOOOOOOOOOOOOOOR | | p iOS IIIS II III ICI III I I 
trx_id:3205 

rseg_id:5 

undo_rec_no:0 

undo_rec_type: TRX_UNDO_UPD_EXIST_REC 

size:41 

space:0 

page_no:318 

offset:724 

1 row in set(0.00 sec) 








用 上 述 同 样 的 方法 定位 到 页 318， 偶 移 量 为 724 的 位 置 ， 得 到 如 下 结 
果 : 





04f82d0 00 00 00 O0 02 fd Oc 00 16 00 00 00 00 32 04 eO 
04f82e0 84 00 00 O1 48 01 10 04 80 00 00 O1 01 03 01 31 
O4f82fO 00 Ob OO O4 80 00 00 O1 03 O1 31 02 d4 00 00 00 





整理 后 得 到 : 





02 fd# 下 一 个 undo 1og 的 开始 位 置 
Oc#undo 1og 类 型 ，TRX_UNDO_UPD_DEL_REC 为 13 
900#undo no 

16#table id 

00#info bits 

00 00 00 32 04 eg#rec trx id 
84 00 00 01 48 01 10#rec 回 深 指 针 
94# 主 键 长 度 

80 00 00 01# 主 键 值 

91#update vector 的 数量 
O3#update vector 列 b 的 编号 
91#update vector 列 的 长 度 
31#update vector 列 的 值 ， 这 里 是 '1' 
00 Qb# 接 下 去 部 分 占用 的 字 节 
99# 列 的 位 置 

94# 列 的 长 度 

80 00 00 01# 列 的 值 

93# 列 的 长 度 

31# 列 的 值 

02 d4#undo 1og 开 始 位 置 的 偏 移 量 























上 面 的 例子 是 更 新 一 个 非 主键 值 ， 知 更 新 的 对 象 是 一 个 主键 值 ， 那 
么 其 产生 的 undo log 完 全 不 同 ， 如 : 





mysql>ROLLBACK; 

Query OK,1 row affected(0.00 sec) 

mysql>UPDATE t SET a-2 WHERE a=1; 

Rows matched:1 Changed:1 Warnings:0 

mysql>SELECT*FROM information schema.INNODB TRX UNDO 

-二 ORDER BY undo rec no*G; 
JOOOOOOOOOOOAOOOOODIOOOOOOOOOR] | pj FECT III III II I Ie 
trx_id:320F 

rseg id:11 


undo. rec no: 

undo rec d TRX UNDO DEL MARK REC 
size:37 

space:0 

page no:324 

offset:492 


trx id:320F 

rseg id:11 

undo. rec no: 

undo rec Se: TRX UNDO INSERT REC 
size:12 

space:0 

page no:336 

offset:272 

2 rows in set(0.00 sec) 





可 以 看 到 ，update 主 键 的 操作 其 实 分 两 步 完 成 。 自 先 将 原 主键 记录 
标记 为 已 删除 ， 因 此 需要 产生 一 个 类 型 为 
TRX UNDO DEL MARK_REC 的 undo log， 之 后 插入 一 条 新 的 记录 ， 
因此 需要 产生 一 个 类 型 为 TRX_UNDO_INSERT_REC 的 undo log. 
undo_rec_no 显 示 了 产生 日 志 的 步骤 。 对 undo log 不 再 详细 进行 分 析 ， 相 
关内 容 和 之 前 介绍 的 并 无 不 同 。 


总 之 ，InnoSQL 数 据 库 提供 的 关于 undo 信 息 的 数据 字典 表 可 以 帮助 
DBA 和 开发 人 员 更 好 地 了 解 当前 各 个 事务 产生 的 undo 信 息 。 


7.2.3 purge 


delete 和 update 操 作 可 能 并 不 直接 删除 原 有 的 数据 。 例 如 ， 对 上 一 小 
节 所 产生 的 表 t 执 行 如 下 的 SQL 语句 : 





DELETE FROM t WHERE a-1; 


表 t 上 列 as 有 聚集 索引 ， 列 b 上 有 辅助 索引 。 对 于 上 述 的 delete 操 作 ， 
通过 前 面 关 于 undo log 的 介绍 已 经 知道 仅 是 将 主键 列 等 于 1 的 记录 delete 
flag 设 置 为 1， 记 录 并 没有 被 删除 ， 即 记录 还 是 存在 于 B+ 树 中 。 其 次 ， 
对 辅助 索引 上 a 等 于 1，b 等 于 1 的 记录 同样 没有 做 任何 处 理 ， 甚 至 没有 产 
A 而 真正 删除 这 行 记 录 的 操作 其 实 被 * 延 时 了， 最 终 在 purge 
ES JÖH o 


purge 用 于 最 终 完成 delete 和 update 操 作 。 这 样 设计 是 因为 InnoDB 存 
储 引 擎 文 持 MVCC， 所 以 记录 不 能 在 事务 提交 时 立即 进行 处 理 。 这 时 其 
他 事物 可 能 正在 引用 这 行 ， 故 InnoDB 存 储 引 擎 需要 保存 记录 之 前 的 版 
本 。 而 是 否 可 以 删除 该 条 记录 通过 purge 来 进行 判断 。 若 该 行 记录 已 不 
被 任何 其 他 事务 引用 ， 那 么 束 可 以 进行 真正 的 delete 操 作 。 可 见 ，purge 
操作 是 清理 之 前 的 delete 和 update 操 作 ， 将 上 述 操作 “最 终 ” 完 成 。 而 实际 
执行 的 操作 为 delete 操 作 ， 清 理 之 前 行 记录 的 版 本 。 


在 前 一 个 小 节 中 已 经 介绍 过 ， 为 了 节省 存储 空间 ，InnoDB 存 储 引 
SK undo log 设 计 是 这 样 的 : 一 个 页 上 允许 多 个 事务 的 undo log 存 在 。 虽 
然 这 不 代表 事务 在 全 局 过 程 中 提交 的 顺序 ， 但 是 后 面 的 事务 产生 的 undo 
log 总 在 最 后 。 此 外 ，InnoDB 存 储 引 擎 还 有 一 个 history 列 表 ， 它 根据 事 
务 提交 的 顺序 ， 将 undo log 进 行 链接 。 如 下 面 的 一 种 情况 : 


在 图 7-17 的 例子 中 ，history list 表 示 按 照 事 务 提交 的 顺序 将 undo log 
进行 组 织 。 在 InnoDB 存 储 引 擎 的 设计 中 ， 先 提交 的 事务 总 在 尾 痊 。 
undo page 存 放 了 undo log， 由 于 可 以 重用 ， 因 此 一 个 undo page 中 可 能 存 
e eee log。trx5 的 灰色 阴影 表示 该 ndo log 还 被 其 他 

务 引 用 。 


在 执行 purge 的 过 程 中 ，InnoDB 存 储 引 擎 首先 从 history list 中 找到 第 
一 个 需要 被 清理 的 记录 ， 这 里 为 tx1， 清 理 之 后 InnoDB 存 储 引 擎 会 在 





























trx1 的 undo log 所 在 的 页 中 继续 寻找 是 人 否 存在 可 以 被 清理 的 记录 ， 这 里 会 
找到 事务 trx3， 接 着 找到 trx5， 但 是 发 现 trx5 被 其 他 事务 所 引用 而 不 能 清 
理 ， 故 去 再 次 去 history list 中 和 查找， 发 现 这 时 最 尾 端的 记录 为 trx2， 接 着 
找到 trx2 所 在 的 页 ， 然 后 依次 再 把 事务 trx6、trx4 的 记录 进行 清理 。 由 于 
undo page2 中 所 有 的 页 都 被 清理 了 ， 因 此 该 ndo page 可 以 被 重用 。 
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undo pagel undo paged 








图 7-17 undo log 与 history 列 表 的 关系 


InnoDB 存 储 引 擎 这 种 先 从 history list 中 找 undo log， 然 后 再 从 undo 
page 中 找 undo log 的 设计 模式 是 为 了 避免 大 量 的 随机 读 取 操作 ， 从 而 提 
高 purge 的 效率 。 


全 局 动态 参数 innodb_purge_batch_size 用 来 设置 每 次 purge 操 作 需 要 
清理 的 undo page 数 量 。 在 InnoDB1.2 之 前 ， 该 参数 的 默认 值 为 20。 而 从 
1.2 版 本 开始 ， 该 参数 的 默认 值 为 300。 通 常 来 说 ， 该 参数 设置 得 越 大 ， 
每 次 回收 的 undo page 也 就 越 多 ， 这 样 可 供 重用 的 undo paget ts, m 
少 了 磁盘 存储 空间 与 分 配 的 开销 。 不 过 ， 奋 该 参数 设置 得 太 大 ， 则 每 次 
需要 purge 处 理 更 多 的 undo page， 从 而 导致 CPU 和 磁盘 IO 过 于 集中 于 对 
undo ”log 的 处 理 ， 使 性 能 下 降 。 因 此 对 该 参数 的 调整 需要 由 有 经 验 的 
DBA 来 操作 ， 并 且 和 需要 长 期 观察 数据 库 的 运行 的 状态 。 正 如 官方 的 
MySQL 数 据 库 手 册 所 说 的 ， 普 通用 户 不 需要 调整 该 参数 。 


当 ImnnoDB 存 储 引 擎 的 压力 非常 大 时 ， 并 不 能 高 效 地 进行 purge 操 
作 。 那 么 history list 的 长 度 会 变 得 越 来 越 长 。 全 局 动态 参数 
innodb_max_purge_lag 用 来 控制 history “list 的 长 度 ， 若 长 度 大 于 该 参数 
时 ， 其 会 “延缓 ?DML 的 操作 。 该 参数 默认 值 为 0， 表 示 不 对 history list 做 
任何 限制 。 当 大 于 0 时 ， 束 会 延缓 DML 的 操作 ， 其 延缓 的 算法 为 : 








delay- ( KXlength(history list)-innodb max purge lag) *10)-5 





delay 的 单位 是 坚 秒 。 此 外 ， 需 要 特别 注意 的 是 ，delay 的 对 象 是 
行 ， 而 不 是 一 个 DML 操 作 。 例 如 当 一 个 update 操 作 需 要 更 新 5 行 数据 
时 ， 每 行 数据 的 操作 都 会 被 delay， 故 总 的 延 时 时 间 为 5*delay。 而 delay 
的 统计 会 在 每 一 次 purge 操 作 完成 后 ， 重 新 进行 计算 。 


InnoDB1.2 版 本 引入 了 新 的 全 局 动态 参数 
innodb_max_purge_lag_delay， 其 用 来 控制 delay 的 最 大 坚 秒 数 。 也 就 是 
当 上 述 计 算得 到 的 delay 值 大 于 该 参数 时 ， 将 delay 设 置 为 
innodb max purge lag delay, X% FH T purget& ZTE Sr SIC f SQL 2E 
程 出 现 无 限制 的 等 竺 。 








7.2.4 group commit 


知事 务 为 非 只 读 事务 ， 则 每 次 事务 提交 时 需要 进行 一 次 fsync 操 作 ， 
以 此 保证 重 做 日 志 都 已 经 写 入 磁盘 。 当 数据 库 发 生 宕 机 时 ， 可 以 通过 重 
做 日 志 进 行 恢复 。 虽 然 固 态 硬盘 的 出 现 提 高 了 磁盘 的 性 能 ， 然 而 磁盘 的 
fsync 性 能 是 有 限 的 。 为 了 提高 磁盘 fsync 的 效率 ， 当 前 数据 库 都 提供 了 
group commit 的 功能 ， 即 一 次 fsync 可 以 刷新 确保 多 个 事务 日 志 被 写 入 文 
件 。 对 于 InnoDB 存 储 引 擎 来 说 ， 事 务 提交 时 会 进行 两 个 阶段 的 操作 : 


1) 修改 内 存 中 事务 对 应 的 信息 ， 并 且 将 日 志 写 入 重 做 日 志 绥 冲 。 
2) 调用 fsync 将 确保 日 志 都 从 重 做 日 志 绥 冲 写 入 磁盘 。 


步骤 2) 相对 步骤 1) 是 一 个 较 慢 的 过 程 ， 这 是 因为 存储 引擎 需要 与 
磁盘 打交道 。 但 当 有 事务 进行 这 个 过 程 时 ， 其 他 事务 可 以 进行 步骤 1) 
的 操作 ， 正 在 提交 的 事物 完成 提交 操作 后 ， 再 次 进行 步骤 2) 时 ， 可 以 
将 多 个 事务 的 重 做 日 志 通 过 一 次 fync 刷 新 到 磁盘 ， 这 样 就 大 大 地 减少 了 
磁盘 的 压力 ， 从 而 提高 了 数据 库 的 整体 性 能 。 对 于 写 入 或 更 新 较为 频繁 
的 操作 ，group commit 的 效果 尤为 明显 。 


然而 在 InnoDB1.2 版 本 之 前 ， 在 开启 二 进 制 日 志 后 ，InnoDB 存 储 引 
擎 的 group commit 功 能 会 失效 ， 从 而 导致 性 能 的 下 降 。 并 且 在 线 环境 多 
使 用 replication 环 境 ， 因 此 二 进 制 日 志 的 选项 基本 都 为 开局 状态 ， 因 此 
这 个 问题 尤为 显著 。 

导致 这 个 问题 的 原因 是 在 开局 二 进 制 日 志 后 ， 为 了 保证 存储 引擎 层 
qo con uem 日 志 的 一 致 性 ， 二 者 之 间 使 用 了 两 阶段 事务 ， 其 步 又 

WP: 

1) 当 事 务 提 交 时 InnoDB 存 储 引 擎 进行 prepare 操 作 。 

2) MySQL 数 据 库 上 层 写 入 二 进 制 日 志 。 

3) InnoDB 存 储 引 警 层 将 日 志 写 入 重 做 日 志文 件 。 


a) 修改 内 存 中 事务 对 应 的 信息 ， 并 且 将 日 志 写 入 重 做 日 志 缓 冲 。 









































bo 调用 fsync 将 确保 日 志 都 从 重 做 日 志 缓 冲 写 入 磁盘 。 


一 旦 步骤 2) 中 的 操作 完成 ， 束 确保 了 事务 的 提交 ， 即 使 在 执行 步 
IRI) 时 数据 库 发 生 了 宕 机 。 此 外 需要 注意 的 是 ， 每 个 步骤 都 需要 进行 
一 次 fsync 操 作 才 能 保证 上 下 两 层 数 据 的 一 臻 性。 步骤 2) 的 fsync 由 参数 
sync_binlog 控 制 ， 步 又 3) 的 fsync 由 参数 innodb_flush_log_at_trx_commit 
控制 。 因 此 上 述 整个 过 程 如 图 7-18 所 示 。 


Session Server Binary Log Engine 
COMMIT 


prepare 





图 7-318 开启 二 进 制 日 志 后 InnoDB 存 储 引 擎 的 提交 过 程 


为 了 保证 MySQL 数 据 库 上 层 二 进 制 日 志 的 写 入 顺序 和 InnoDB 层 的 
事务 提交 顺序 一 致 ，MySQL 数 据 库 内 部 使 用 了 prepare_commit mutex 这 
个 锁 。 但 是 在 局 用 这 个 锁 之 后 ， 步 骤 3) 中 的 步骤 a) 步 不 可 以 在 其 他 事 
务 执 行 步 骤 b) 时 进行 ， 从 而 导致 了 group commit 失 效 。 


然而 ， 为 什么 需要 保证 MySQL 数 据 库 上 层 二 进 制 日 志 的 写 入 顺序 
和 InnoDB 层 的 事务 提交 顺序 一 致 呢 ? 这 时 因为 备份 及 恢复 的 需要 ， 例 
如 通过 工具 xtrabackup 或 者 ibbackup 进 行 备份 ， 并 用 来 建立 replication， 
如 图 7-19 所 示 。 











Tl D IE Binary Log InnoDB 
Prepare 


m| 


Write @ 100 


Write @ 300 





z aa 


| | Commit | | 


图 7-19 InnoDB4¥ MI Ez St esc IUS 3 MySQL ZU E LJ 
进 制 日 志 不 同 


可 以 看 到 知 通过 在 线 备 份 进行 数据 库 恢 复 来 重新 建立 replication， 
事务 T1 的 数据 会 产生 丢失 。 因 为 在 InnoDB 存 储 引 擎 层 会 检测 事务 T3 在 
上 下 两 层 都 完成 了 提交 ， 不 需要 再 进行 恢复 。 因 此 通过 锁 
prepare_commit_mutex 以 串 行 的 方式 来 保证 顺序 性 ， 然 而 这 会 使 group 
commit 无 法 生效 ， 如 图 7-20 所 示 。 
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图 7-20 通过 锁 prepare_commit_mutex 保 证 InnoDB 存 储 引 警 层 事务 提 
区 与 MySQL 数据 库 上 层 的 二 进 制 日 志 写 入 的 顺序 性 





这 个 问题 最 早 在 2010 年 的 MySQL 数 据 库 大 会 中 提出 ，Facebook 
MySQL 技 术 组 ，Percona 公 司 都 提出 过 解决 方 采 。 最 后 由 MariaDB 数 据 
库 的 开发 人 员 Kristian ”Nielsen 完 成 了 最 终 的 “完美 ”解决 方案 。 在 这 种 情 
况 下 ， 不 但 MySQL 数 据 库 上 层 的 二 进 制 日 志 写 入 是 group — commit, 
InnoDB 存 储 引 擎 层 也 是 group commit 的 。 此 外 还 移 除 了 原先 的 锁 
prepare commit mutex， 从 而 大 大 提高 了 数据 库 的 整体 性 。MySQL 5.6 
采用 了 类 似 的 实现 方式 ， 并 将 其 称 为 Binary Log 
Commit (BLGC) . 





Group 


MySQL 5.6 BLGC 的 实现 方式 是 将 事务 提交 的 过 程 分 为 几 个 步骤 来 
完成 ， 如 图 7-21 所 示 。 
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图 7-21 MySQL 5.6 BLGC 的 实现 方式 











在 MySQL 数 据 库 上 层 进行 提交 时 首先 按 顺 序 将 其 放 入 一 个 队列 
中 ， 队 列 中 的 第 一 个 事务 称 为 leader， 其 他 事务 称 为 follower，leader 控 
制 着 follower 的 行为 。BLGC 的 步骤 分 为 以 下 三 个 阶段 : 


DFlush 阶 段 ， 将 每 个 事务 的 二 进 制 日 志 写 入 内 存 中 。 
DSync 阶 段 ， 将 内 存 中 的 三 进 制 日 志 刷 新 到 磁盘 ， 厦 队列 中 有 多 个 


事务 ， 那 么 仅 一 次 fsync 操 作 束 完成 了 二 进 制 日 志 的 写 入 ， 这 束 是 
BLGC. 


DCommit 阶 段 ，leader 根 据 顺 序 调用 存储 引擎 层 事务 的 提交 ， 
InnoDB 存 储 引擎 本 就 文 持 group commit， 因 此 修复 了 原先 由 于 锁 


prepare commit mutex 导 致 group commit 失 效 的 问题 。 


当 有 一 组 事务 在 进行 Commit 阶 段 时 ， 其 他 新 事物 可 以 进行 Flush 阶 
段 ， 从 而 使 group commit 不断 生效 。 当 然 group commit 的 效果 由 队列 中 
事务 的 数量 决定 ， 知 每 次 队列 中 仅 有 一 个 事务 ， 那 么 可 能 效果 和 之 前 差 
不 多 ， 甚 至 会 更 差 。 但 当 提 交 的 事务 越 多 时 ，group commit 的 效果 越 明 
显 ， 数 据 库 性 能 的 提升 也 就 越 大 。 


参数 binlog_max_flush_queue_time 用 来 控制 Flush 阶 段 中 等 竺 的 时 
间 ， 即 使 之 前 的 一 组 事务 完成 提交 ， 当 前 一 组 的 事务 也 不 马上 进入 Sync 
阶段 ， 而 是 至 少 需 要 等 待 一 段 时 间 。 这 样 做 的 好 处 是 group commit 的 事 
务 数量 更 多 ， 然 而 这 也 可 能 会 导致 事务 的 啊 应 时 间 变 慢 。 该 参数 的 默认 
值 为 0%， 且 推荐 设置 依然 为 0。 除 非 用 户 的 MySQL 数 据 库 系 统 中 有 着 大 
EE 《如 100 个 连接 ) ， 并 且 不 断 地 在 进行 事务 的 写 入 或 更 新 操 














7.3 ”事务 控制 语句 


在 MySQL 命 令 行 的 默认 设置 下 ， 事 务 都 是 自动 提交 (auto 

commit) 的 ， 即 执行 SQL 语句 后 束 会 马上 执行 COMMIT 操 作 。 因 此 要 最 
式 地 开启 一 个 事务 需 使 用 命令 BEGIN、START _ TRANSACTION， 或 者 
执行 命令 SET AUTOCOMMIT=0， 禁 用 当前 会 话 的 自动 提交 。 每 个 数据 
库 厂 商 自 动 提 交 的 设置 都 不 相同 ， 每 个 DBA 或 开发 人 员 需 要 非常 明白 这 
一 点 ， 这 对 之 后 的 SQL 编程 会 有 非凡 的 意义 ， 因 此 用 户 不 能 以 之 前 的 经 
验 来 判断 MySQL 数 据 库 的 运行 方式 。 在 具体 介绍 其 含义 之 前 ， 先 来 看 
看 用 户 可 以 使 用 哪些 事务 控制 语句 。 


DSTART TRANSACTION|BEGIN: 显 式 地 开启 一 个 事务 。 


口 COMMIT: 要 想 使 用 这 个 语句 的 最 简 形式 ， 只 需 发 出 
COMMIT。 也 可 以 更 详细 一 些 ， 写 为 COMMIT _ WORK， 不 过 这 二 者 几 
COMMIT 会 提交 事务 ， 并 使 得 已 对 数据 库 做 的 所 有 修改 成 
为 永久 性 的 。 


DROLLBACK: 要 想 使 用 这 个 语句 的 最 简 形 式 ， 只 需 发 出 
ROLLBACK。 同 样 地 ， 也 可 以 写 为 ROLLBACK WORK， 但 是 二 者 几乎 
回 滚 会 结束 用 户 的 事务 ， 并 撤销 正在 进行 的 所 有 未 提交 的 修 
Wo 











DSAVEPOINT identifier : SAVEPOINT 人 允许 在 事务 中 创建 一 个 保存 
点 ， 一 个 事务 中 可 以 有 多 个 SAVEPOINT。 





DRELEASE SAVEPOINT identifier: 删除 一 个 事务 的 保存 点 ， 当 没 
有 一 个 保存 点 执行 这 人 句 语 句 时 ， 会 抛 出 一 个 异常 。 


OROLLBACK TO[SAVEPOINT]identifier: 这 个 语句 与 
SAVEPOINT 命 令 一 起 使 用 。 可 以 把 事务 回 滚 到 标记 点 ， 而 不 回 滚 在 此 
标记 点 之 前 的 任何 工作 。 例 如 可 以 发 出 两 条 UPDATE 语 句 ， 后 面 跟 一 个 
SAVEPOINT， 然 后 又 是 两 条 DELETE 语 句 。 如 果 执 行 DELETE 语 句 期 间 
出 现 了 某 种 异常 情况 ， 并 且 捕 获 到 这 个 异常 ， 同 时 发 出 了 ROLLBACK 
TO SAVEPOINT 命 令 ， 事 务 就 会 回 滚 到 指定 的 SAVEPOINT， 撤 销 
DELETE 完 成 的 所 有 工作 ， 而 UPDATE 语 句 完成 的 工作 不 受 影 响 。 











口 SET TRANSACTION: 这 个 语句 用 来 设置 事务 的 隔离 级 别 。 
InnoDB 存 储 引擎 提供 的 事务 隔离 级 别 有 : READ UNCOMMITTED、 
READ COMMITTED. REPEATABLE READ、SERIALIZABLE。 


START TRANSACTION, BEGINI 4) 4h FJ EL AEMySQL ip íT T Si 
UU JEJE PS. (TEE, MySQLA FERAT SS A 
动 将 BEGIN 识 别 为 BEGIN...END， 因 此 在 存储 过 程 中 只 能 使 用 START 
TRANSACTION 语 名 来 开启 一 个 事务 。 











COMMIT 和 COMMIT WORK 语句 基本 是 一 致 的 ， 都 是 用 来 提交 事 
务 。 不 同 之 处 在 于 COMMIT WORK 用 来 控制 事务 结束 后 的 行为 是 
CHAIN 还 是 RELEASE 的 。 如 果 是 CHAIN 方 式 ， 那 么 事务 就 变 成 了 链 事 
务 。 


用 户 可 以 通过 参数 completion_type 来 进行 控制 ， 该 参数 默认 为 0， 
表示 没有 任何 操作 。 在 这 种 设置 下 COMMIT 和 COMMIT WORK 56 
等 价 的 。 当 参数 completion_type 的 值 为 1 时 ，COMMIT ” WORK 等同 于 
AND CHAIN， 表 示 马 上 目 动 开局 一 个 相同 隅 离 级 别 的 事务 ， 

H: 





mysql>CREATE TABLE t(a INT,PRIMARY KEY(a))ENGINE=INNODB; 
Query OK,0 rows affected(0.00 sec) 
mysql-SELECTQGautocommitNG; 


QQautocommit:1 

1 row in set(0.00 sec) 
mysql-SETOGOcompletion type-1; 

Query OK,0 rows affected(0.00 sec) 
mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO t SELECT 1; 

Query OK,1 row affected(0.00 sec) 
Records:1 Duplicates:0 Warnings:O 
mysql>COMMIT WORK; 

Query OK,0 rows affected(0.01 sec) 
mysql>INSERT INTO t SELECT 2; 

Query OK,1 row affected(0.00 sec) 
Records:1 Duplicates:0 Warnings:O 
mysql>INSERT INTO t SELECT 2; 

ERROR 1062(23000):Duplicate entry'2'for key'PRIMARY' 
mysql>ROLLBACK; 

Query OK,0 rows affected(0.00 sec) 
# 注 意 回 滚 之 后 只 有 1 这 个 记录 ， 而 没有 2 这 个 记录 
mysql>SELECT*FROM t\G; 


a:1 
1 row in set(0.00 sec) 





在 这 个 示例 中 我 们 设置 completion_type 为 1， 第 一 次 通过 COMMIT 
WORK 来 插入 1 这 个 记录 。 之 后 插入 记录 2 时 我 们 并 没有 用 BEGIN (或 者 
START TRANSACTION) 来 显 式 地 开启 一 个 事务 ， 之 后 再 插入 一 条 重 
复 的 记录 2 就 会 抛 出 异常 。 接 着 执行 ROLLBACK 操 作 ， 最 后 发 现 只 有 1 
这 一 个 记录 ，2 并 没有 被 插入 。 因 为 completion_type 为 1 时 ，COMMIT 








WORK 会 自动 开启 一 个 链 事 务 ， 第 二 条 INSERT INTO t SELECT 2 语句 
是 在 同一 个 事务 内 的 ， 因 此 回 滚 后 2 这 条 记录 并 没有 被 插入 表 t 中 。 


参数 completion_type 为 2 时 ，COMMIT WORK 等 同 于 COMMIT AND 
RELEASE。 在 事务 提交 后 会 自动 断 开 与 服务 器 的 连接 ， 如 : 











mysql>SET@@completion_type=2; 

Query OK,0 rows affected(0.00 sec) 
mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO t SELECT 3; 

Query OK,1 row affected(0.00 sec) 
Records:1 Duplicates:0 Warnings:0 
mysql>COMMIT WORK; 

Query OK,0 rows affected(0.01 sec) 
mysql>SELECT@@version\G; 

ERROR 2006(HY000):MySQL server has gone away 
No connection.Trying to reconnect... 
Connection id:54 

Current database:test 


@@version:5.1.45-log 
1 row in set(0.00 sec) 





通过 上 面 的 示例 可 以 发 现 ， 当 将 参数 completion_type 设 置 为 2 时 ， 
COMMIT WORK 后 用 户 再 执行 语句 SELECT@@version 会 出 现 ERROR 
2006 CHY000) : MySQL server has gone away 的 错误 。 抛 出 该 异常 的 原 
因 是 当前 会 话 已 经 在 上 次 执行 COMMIT WORK 语 句 后 与 服务 器 断 开 了 
连接 。 

ROLLBACK 和 ROLLBACK WORK 与 COMMIT 和 COMMIT WORK 
的 工作 一 样 ， 这 里 不 再 进行 装 述 。 


SAVEPOINT 记 录 了 一 个 保存 点 ， 可 以 通过 ROLLBACK TO 
SAVEPOINT 来 回 滚 到 某 个 保存 点 ， 但 是 如 果 回 滚 到 一 个 不 存在 的 保存 
点 ， 会 抛 出 异常 : 








mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>ROLLBACK TO SAVEPOINT t1; 

ERROR 1305(42000):SAVEPOINT t1 does not exist 





InnoDB 存 储 引 擎 中 的 事务 都 是 原子 的 ， 这 说 明 下 述 两 种 情况 : TÀ 
成 事务 的 每 条 语句 都 会 提交 【成 为 永久 ) ， 或 者 所 有 语句 都 回 滚 。 这 种 
保护 还 延伸 到 单个 的 语句 。 一 条 语句 要 么 完全 成 功 ， 要 么 完全 回 滚 〈 注 
意 ， 这 里 说 的 是 语句 回 深 ) 。 因 此 一 条 语句 失败 并 抛 出 异常 时 ， 并 不 会 
导致 先前 已 经 执行 的 语句 自动 回 深 。 所 有 的 执行 都 会 得 到 保留 ， 必 须 由 
用 户 自己 来 决定 是 否 对 其 进行 提交 或 回 深 的 操作 。 如 : 














mysql- CREATE TABLE t(a INT,PRIMARY KEY(a))ENGINE-INNODB; 
Query OK,0 rows affected(0.00 sec) 

mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 

mysql>INSERT INTO t SELECT 1; 

Query OK,1 row affected(0.00 sec) 

Records:1 Duplicates:0 Warnings:O 

mysql>INSERT INTO t SELECT 1; 

ERROR 1062(23000):Duplicate entry'1'for key'PRIMARY' 
mysql>SELECT*FROM t\G; 


ait 
1 row in set(0.00 sec) 





可 以 看 到 ， 插 入 第 二 记录 1 时 ， 因 为 重复 的 关系 抛 出 了 1062 的 错 
误 ， 但 是 数据 库 并 没有 进行 自动 回 演 ， 这 时 事务 仍 需 要 用 户 显 式 地 运行 
COMMIT 或 ROLLBACK 命 令 。 





另 一 个 容易 犯 的 错误 是 ROLLBACK TO SAVEPOINT, BRA 
ROLLBACK， 但 其 并 不 是 真正 地 结束 一 个 事务 ， 因 此 即使 执行 了 
ROLLBACK TO SAVEPOINT， 之 后 也 需要 显 式 地 运行 COMMIT 或 
ROLLBACK 命 令 。 





mysql>CREATE TABLE t(a INT,PRIMARY KEY(a))ENGINE-INNODB; 
Query OK,0 rows affected(0.00 sec) 
mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO t SELECT 1; 
Query OK,1 row affected(0.00 sec) 
Records:1 Duplicates:0 Warnings:O 
mysql>SAVEPOINT t1; 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO t SELECT 2; 
Query OK,1 row affected(0.00 sec) 
Records:1 Duplicates:0 Warnings:O 
mysql>SAVEPOINT t2; 

Query OK,0 rows affected(0.00 sec) 
mysql>RELEASE SAVEPOINT t1; 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO t SELECT 2; 
ERROR 1062(23000):Duplicate entry'2'for key'PRIMARY' 
mysql>ROLLBACK TO SAVEPOINT t2; 
Query OK,0 rows affected(0.00 sec) 
mysql>SELECT*FROM t; 

*--- 


lal 
*--- 
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2 rows in set(0.00 sec) 
mysql>ROLLBACK; 

Query OK,0 rows affected(0.00 sec) 
mysql>SELECT*FROM t; 

Empty set(0.00 sec) 








可 以 看 到 ， 在 上 面 的 例子 中 ， 虽 然 在 发 生 重复 错误 后 用 户 通过 
ROLLBACK TO SAVEPOINT 世 2 命令 回 滚 到 了 保存 点 忆 ， 但 是 事务 此 时 
没有 结束 。 再 运行 命令 ROLLBACK 后 ， 事 务 才 会 完整 地 回 滚 。 这 里 再 
一 次 提醒 ，ROLLBACK TO SAVEPOINT 命 令 并 不 真正 地 结束 事务 。 


7.4” 隐 式 提 交 的 SQL 语 句 


以 下 这 些 SQL 语 句 会 产生 一 个 隐 式 的 提交 操作 ， 即 执行 完 这 些 语句 
后 ， 会 有 一 个 隐 式 的 COMMIT 操 作 。 


QDDL 语 句 : ALTER DATABASE...UPGRADE DATA 
DIRECTORY NAME, ALTER EVENT, ALTER PROCEDURE, 
ALTER TABLE, ALTER VIEW, CREATE DATABASE, CREATE 
EVENT, CREATE INDEX, CREATE PROCEDURE, CREATE 
TABLE, CREATE TRIGGER, CREATE VIEW, DROP DATABASE, 
DROP EVENT, DROP INDEX, DROP PROCEDURE, DROP 
TABLE, DROP TRIGGER, DROP VIEW, RENAME TABLE, 
TRUNCATE TABLE. 





口 用 来 隐 式 地 修改 MySQL 架 构 的 操作 : CREATE USER, DROP 
USER、GRANT、RENAME USER、REVOKE、SET PASSWORD。 


口 管理 语句 : ANALYZE TABLE, CACHE INDEX, CHECK 
TABLE. LOAD INDEX INTO CACHE, OPTIMIZE TABLE. REPAIR 
TABLE. 


注意 ”我 发 现 Microsoft SQL Server 的 数据 库 管 理 员 或 开发 人 员 往 往 
忽视 对 于 DDL 语 句 的 隐 式 提交 操作 ， 因 为 在 Microsoft SQL Server 数 据 库 
中 ， 即 使 是 DDL 也 是 可 以 回 深 的 。 这 和 InnoDB 存 储 引 擎 、Oracle 这 些 数 
据 库 完全 不 同 。 


另外 需要 注意 的 是 ，TRUNCATE TABLE 语 句 是 DDL， 因 此 虽然 和 
对 整 张 表 执行 DELETE 的 结果 是 一 样 的 ， 但 它 是 不 能 被 回 滚 的 〈 这 又 是 
和 Microsoft SQL Server 数 据 不 同 的 地 方 ) 。 











mysql>SELECT*FRM t\G; 


a:2 

2 rows in set(0.00 sec) 

mysql- BEGIN; 

Query OK,0 rows affected(0.01 sec) 
mysql>TRUNCATE TABLE t; 

Query OK,0 rows affected(0.00 sec) 
mysql>ROLLBACK; 

Query OK,0 rows affected(0.00 sec) 
mysql>SELECT*FROM t; 

Empty set(0.00 sec) 


p—MM——M—M———M————————— ——O 


75 ”对 于 事务 操作 的 统计 


由 于 InnoDB 存 储 引擎 是 文 持 事 务 的 ， 因 此 ImnoDB 存 储 引 擎 的 应 用 
需要 在 考虑 每 秒 请 求 数 (Question Per Second, QPS) 的 同时 ， 应 该 关 
注 每 秒 事 务 处 理 的 能 力 (Transaction Per Second, TPS) 。 


计算 TPS 的 方法 是 (com commit-com rollback) /time。 但 是 利用 这 
种 方法 进行 计算 的 前 提 是 : 所 有 的 事务 必须 都 是 显 式 提交 的 ， 如 果 存 在 
隐 式 地 提交 和 回 深 ( 默 认 autocommit=1) ， 不 会 计算 到 com_commit 和 
com_rollback 变 量 中 。 如 : 








ETTET TETIT TET ETTITA SSCS IGG ISG IGE IE 
Variable_name:Com_commit 

Value:5 

1 row in set(0.00 sec) 

mysql>INSERT INTO t SELECT 3; 

Query OK,1 row affected(0.00 sec) 

Records:1 Duplicates:0 Warnings:0 

mysql>SELECT*FROM t\G; 


FOI TOTTI ITI TO TOR IO I OWE ERR RRR IRI III RRR AE 
aii 
XOKOOROROEOROERCE RO ROEOROROEOROOR OR ROIG 2. OW'TTERXAA OH IDOOHORHORHOHOHOHORH A 
a:2 
FIO TO TO IO I BOWE EERE RRR RRR IRE 
a:3 


JOOOOOOOOOOOOOOOOOOOOOOOOOIOR] 6 QI OCIS III ICICI III ICIS I II Ie 
Variable_name:Com_commit 

Value:5 

1 row in set(0.00 sec) 





MySQL 数 据 库 中 另外 还 有 两 个 参数 handler_commit 和 
handler rollback 用 于 事务 的 统计 操作 。 但 是 我 注意 到 这 两 个 参数 在 
MySQL 5.1 中 可 以 很 好 地 用 来 统计 InnoDB 存 储 引 擎 显 式 和 隐 式 的 事务 提 
交 操 作 ， 但 是 在 InnoDB Plugin 中 这 两 个 参数 的 表现 有 些 “ 怪 异 ”， 并 不 能 
很 好 地 统计 事务 的 次 数 。 所 以 ， 如 果 用 户 的 程序 都 是 显 式 控制 事务 的 提 
克 和 回 深 ， 那 么 可 以 通过 com_commit 和 com _rollback 进 行 统计 。 如 果 不 
是 ， 那 么 情况 就 显得 有 些 复杂 。 











7.6 SEE BB Ail 


令 人 惊讶 的 是 ， 大 部 分 数据 库 系统 都 没有 提供 真正 的 隔离 性 ， 最 初 
或 许 是 因为 系统 实现 者 并 没有 真正 理解 这 些 问 题 。 如 今 这 些 问题 已 经 弄 
清楚 了 ， 但 是 数据 库 实 现 者 在 正确 性 和 性 能 之 间 做 了 妥协 。ISO 和 ANIS 
SQL 标准 制定 了 四 种 事务 隔离 级 别 的 标准 ， 但 是 很 少 有 数据 库 厂 商 遵循 
这 些 标准 。 比 如 Oracle 数 据 库 就 不 支持 READ UNCOMMITTED 和 
REPEATABLE READ 的 事务 隔离 级 别 。 


SQL 标 准 定义 的 四 个 隔离 级 别 为 : 


DREAD UNCOMMITTED 





LIREAD COMMITTED 
LIREPEATABLE READ 
LISERIALIZABLE 


READ UNCOMMITTED 称 为 浏览 访问 Cbrowse access) ， 仅 仅 针 对 
事务 而 言 的 。READ COMMITTED 称 为 游标 稳定 (cursor stability) 。 
REPEATABLE READ 是 2.9999。 的 隔离 ， 没 有 弥 读 的 保护 。 
SERIALIZABLE 称 为 隔离 ， 或 3 的 隔离 。SQL 和 SQL2 标 准 的 默认 事务 
隔离 级 别 是 SERIALIZABLE。 


InnoDB 存 储 引擎 默认 文 持 的 隔离 级 别 是 REPEATABLE READ, 但 
是 与 标准 SQL 不 同 的 是 ，InnoDB 存 储 引 擎 在 REPEATABLE READ 事务 
隔离 级 别 下 ， 使 用 NextrKey Lock 锁 的 算法 ， 因 此 避免 幻 读 的 产生 。 这 
与 其 他 数据 库 系统 (如 Microsoft SQL Server 数 据 库 ) 是 不 同 的 。 所 以 
说 ，InnoDB 存 储 引 擎 在 默认 的 REPEATABLE READ 的 事务 隔离 级 别 下 
己 经 能 完全 保证 事务 的 隅 离 性 要 求 ， 即 达到 SQL 标准 的 SERIALIZABLE 
隔离 级 别 。 


隔离 级 别 越 低 ， 事 务 请 求 的 锁 越 少 或 保持 锁 的 时 间 就 越 短 。 这 也 是 
为 什么 大 多 数 数据 库 系统 默认 的 事务 隔离 级 别 是 READ COMMITTED. 


据 了 解 ， 大 部 分 的 用 户 质 疑 SERIALIZABLE 隔 离 级 别 带 来 的 性 能 问 





题 ， 但 是 根据 Jim GrayfE (Transaction Processing》 一 书 中 指出 ， 两 者 的 
开销 几乎 是 一 样 的 ， 甚 至 SERIALIZABLE 可 能 更 优 !!! 因 此 在 InnoDB 存 
储 引 擎 中 选择 REPEATABLE READ 的 事务 隔离 级 别 并 不 会 有 任何 性 能 
的 损失 。 同 样 地 ， 即 使 使 用 READ COMMITTED 的 隔离 级 别 ， 用 户 也 不 
会 得 到 性 能 的 大 幅度 提升 。 


在 InnoDB 存 储 引 黎 中 ， 可 以 使 用 以 下 命令 来 设置 当前 会 话 或 全 局 
的 事务 隔离 级 别 : 








SET[GLOBAL|SESSION]TRANSACTION ISOLATION LEVEL 


READ UNCOMMITTED 
|READ COMMITTED 
|REPEATABLE READ 
| SERIALIZABLE 





如 果 想 在 MySQL 数 据 库 启动 时 就 设置 事务 的 默认 隔离 级 别 ， 那 就 
需要 修改 MySQL 的 配置 文件 ， 在 [mysqld] 中 添加 如 下 行 : 





[mysqld] 
transaction-isolation=READ-COMMITTED 





查看 当前 会 话 的 事务 隅 离 级 别 ， 可 以 使 用 : 





mysql-—SELECTQQtx isolation'*G6; 

n""-——————— — —— d. TOW* E XOOOOOOOIOOIOOOOOOOOORR 
QQtx isolation:REPEATABLE-READ 

1 row in set(0.01 sec) 








查看 全 局 的 事务 隔离 级 别 ， 可 以 使 用 : 





mysql>SELECT@@global.tx_isolation\G; 

FOI ITO TO TOTO IO IIT TOR IR IK ZL TOW E XOOODOOOOIOOOOOOOOOOOORR 
@@global.tx_isolation: REPEATABLE -READ 

1 row in set(0.00 sec) 





在 SERIALIABLE 的 事务 隔离 级 别 ，InnoDB 存 储 引 擎 会 对 每 个 
SELECT 语句 后 自动 加 上 LOCK IN SHARE MODE， 即 为 每 个 读 取 操作 
加 一 个 共享 锁 。 因 此 在 这 个 事务 隅 离 级 别 下 ， 读 占用 了 锁 ， 对 一 致 性 的 
非 锁 定 读 不 再 予以 文 持 。 这 时 ， 事 务 隔离 级 别 SERIALIZABLE 符 合 数据 
库 理论 上 的 要 求 ， 即 事务 是 well-formed 的 ， 并 且 是 two-phrased 的 。 有 兴 
趣 的 读者 可 进一步 研究 。 





为 InhnoDB 存 储 引 擎 在 REPEATABLE READ 隔离 级 别 下 就 可 以 达 
到 3° 的 隔离 ， 因 此 一 般 不 在 本 地 事务 中 使 用 SERIALIABLE 的 隔离 级 
别 。SERIALIABLE 的 事务 隔离 级 别 主要 用 于 InnoDB 存 储 引 擎 的 分 布 式 
事务 。 


在 READ COMMITTED 的 事务 隔离 级 别 下 ， 除 了 唯一 性 的 约束 检 碍 
及 外 键 约束 的 检查 需要 gap lock，InnoDB 存 储 引 擎 不 会 使 用 gap lock 的 锁 
算法 。 但 是 使 用 这 个 事务 隔离 级 别 需 要 注意 一 些 问题 。 首 先 ， 在 
MySQL 5.141, READ ”COMMITTED 事 务 隔离 级 别 默认 只 能 工作 在 
replication 〈 复 制 ) 二 进 制 日 志 为 ROW 的 格式 下 。 如 果 二 进 制 日 志 工作 
在 默认 的 STATEMENT 下 ， 则 会 出 现 如 下 的 错误 : 





mysql>CREATE TABLE a( 

->b INT,PRIMARY KEY(b) 

-2)JENGINE-INNODB; 

Query OK,0 rows affected(0.01 sec) 

mysql>SET@@tx_isolation='READ-COMMITTED'; 

Query OK,0 rows affected(0.00 sec) 

mysql-—SELECTQQtx isolation'*G; 

FOI TOTO TOTO ITI TORI I A d. TOW E XOOOOOOOIOOOOOOOOOOOORR 

QQtx isolation:REPEATABLE-READ 

1 row in set(0.00 sec) 

mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 

mysql>INSERT INTO a SELECT 1; 

ERROR 1598(HY000):Binary logging not possible.Message:Transaction level'READ-COMMITTED'in InnoDB is not safe for binlog 
mode'STATEMENT ' 








在 MySQL 5.0 版 本 以 前 ， 在 不 支持 ROW 格式 的 二 进 制 日 志 时 ， 也 许 
有 人 知道 通过 将 参数 innodb_locks_unsafe_for_binlog 设 置 为 1 可 以 在 二 进 
制 日 志 为 STATEMENT 下 使 用 READ COMMITTED 的 事务 隔离 级 别 : 





mysql>SELCT@@version\G 


@@version:5.0.77-log 
1 row in set(0.00 sec) 
mysql>SHOW VARIABLES LIKE'innodb_locks_unsafe_for_binlog'\G; 


OK IR KK IR IK IK IK KK TOK IK IKK pg RR RR ROK ko koe ke de ko RR de ee 


Value:ON 

1 row in set(0.00 sec) 
mysql>SET@@tx_isolation='READ-COMMITTED'; 
Query OK,0 rows affected(0.00 sec) 
mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO a SELECT 1; 
Query OK,0 rows affected(0.00 sec) 
mysql>COMMIT; 

Query OK,0 rows affected(0.00 sec) 
mysql>SELECT*FROM a\G; 


mys >SELECT*FRON aNG; A" 
D MN AONA SUM 
oa eat ee 
ee nl 
b:5 


4 rows in set(0.00 sec) 





接着 在 master 上 开局 一 个 会 话 A 执行 如 下 事务 ， 并 且 不 要 提交 : 





#Session A on master 

mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql DELETE FROM a WHERE b<=5; 
Query OK,4 rows affected(0.01 sec) 





同样 ， 在 master 上 开局 另 一 个 会 话 B， 执 行 如 下 事务 ， 并 且 提 区 : 





#Session B on master 

mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>INSERT INTO a SELECT 3; 
Query OK,0 rows affected(0.01 sec) 
mysql>COMMIT; 

Query OK,0 rows affected(0.00 sec) 





接着 会 话 A 提 交 ， 并 查看 表 a 中 的 数据 : 





#Session A on master 
mysql>COMMIT; 

Query OK,0 rows affected(0.00 sec) 
mysql-SELECT*FROM a\G; 





但 是 在 slave 上 看 到 的 结果 却 是 : 





#Slave 
mysql>SELECT*FROM a; 
Empty set(0.00 sec) 





可 以 看 到 ， 数 据 产生 了 不 一 致 。 导 致 这 个 问题 发 生 的 原因 有 两 点 : 


口 在 READ COMMITTED 事 务 隔离 级 别 下 ， 事 务 没 有 使 用 gap lock 
进行 锁定 ， 因 此 用 户 在 会 话 B 中 可 以 在 小 于 等 于 5 的 范围 内 插入 一 条 记 
3 


DSTATEMENT 格 式 记 录 的 是 master 上 产生 的 SQL 语 句 ， 因 此 在 
master 服 务 器 上 执行 的 顺序 为 先 删 后 插 ， 但 是 在 STATEMENT 格 式 中 记 
录 的 却 是 先 插 后 删 ， 逻 辑 顺 序 上 产生 了 不 一 致 。 


要 避免 主 从 不 一 致 的 问题 ， 只 需 解 决 上 述 问题 中 的 一 个 就 能 保证 数 
据 的 同步 了 。 如 使 用 READ REPEATABLE 的 事务 隔离 级 别 可 以 避免 上 
述 第 一 种 情况 的 发 生 ， 也 就 避免 了 master 和 slave 数 据 不 一 致 问题 的 产 
^E. 


在 MySQL 5.1 版 本 之 后 ， 因 为 文 持 了 ROW 格式 的 二 进 制 日 志 记 录 格 
式 ， 避 免 了 第 二 种 情况 的 发 生 ， 所 以 可 以 放心 使 用 READ COMMITTED 
的 事务 隔离 级 别 。 但 即使 不 使 用 READ COMMITTED 的 事务 隔离 级 别 ， 
也 应 该 考虑 将 二 进 制 日 志 的 格式 更 换 成 ROW， 因 为 这 个 格式 记录 的 是 
行 的 变更 ， 而 不 是 简单 的 SQL 语句 ， 所 以 可 以 避免 一 些 不 同步 现象 的 产 
生 ， 进 一 步 保 证 数据 的 同步 。InnoDB 存 储 引擎 的 创始 人 HeikkiTuuri 也 在 
http: // bugs.mysql.com/bug.php?id=33210 这 个 帖子 中 建议 使 用 ROW 格 式 
HN — XE fill A e 





7.7 4 ARES 
7.7.1 _ MySQL 数据 库 分 布 式 事务 


InnoDB 存 储 引 擎 提供 了 对 XA 事 务 的 文 持 ， 并 通过 XA 事 务 来 文 持 分 
布 式 事务 的 实现 。 分 布 式 事务 指 的 是 允许 多 个 独立 的 事务 资源 
(transactional resources) 参与 到 一 个 全 局 的 事务 中 。 事 务 资源 通常 是 关 
系 型 数据 库 系 统 ， 但 也 可 以 是 其 他 类 型 的 资源 。 全 局 事务 要 求 在 其 中 的 
所 有 参与 的 事务 要 么 都 提交 ， 要 么 都 回 滚 ， 这 对 于 事务 原 有 的 ACID 要 
求 又 有 了 提高 。 另 外 ， 在 使 用 分 布 式 事务 时 ，InnoDB 存 储 引 擎 的 事务 
隔离 级 别 必 须 设 置 为 SERIALIZABLE。 


XA 事 务 允 许 不 同 数据 库 之 间 的 分 布 式 事务 ， 如 一 人 台 服 务 喜 是 
MySQL 数 据 库 的 ， 男 一 台 是 Oracle 数 据 库 的 ， 又 可 能 还 有 一 台 服 务 嚣 是 
SQL Server 数 据 库 的 ， 只 要 参与 在 全 局 事务 中 的 每 个 节点 都 文 持 XA 事 
务 。 分 布 式 事务 可 能 在 银行 系统 的 转账 中 比较 常见 ， 如 用 户 David 需 要 
从 上 海 转 10 000 元 到 北京 的 用 户 Mariah 的 银行 卡 中 : 














#Bank@Shanghai: 

UPDATE accoun t SET money=money-10000 WHERE user='David'; 
#Bank@Beijing 

UPDATE accoun t SET money=money+10000 WHERE user='Mariah'; 


在 这 种 情况 下 ， 一 定 需要 使 用 分 布 式 事务 来 保证 数据 的 安全 。 如 宋 
发 生 的 操作 不 能 全 部 提交 或 回 滚 ， 那 么 任何 一 个 结 点 出 现 问题 都 会 导致 
严重 的 结 末 。 要 么 是 David 的 账户 被 扣 和 天 ， 但 是 Mariah 没 收 到 ， 又 或 者 
是 David 的 账户 没有 扣 球 ，Mariah 却 收 到 钱 了 。 


XA 事务 由 一 个 或 多 个 资源 管理 器 (Resource Managers) 、 一 个 事 
务 管理 器 (Transaction Manager) 以 及 一 个 应 用 程序 (Application 
Program) 组 成 。 


QURE PR: 提供 访问 事务 资源 的 方法 。 通 常 一 个 数据 库 就 是 一 
个 资源 管理 器 。 

口 事务 管理 器 :协调 参与 全 局 事务 中 的 各 个 事务 。 需 要 和 参与 全 局 
事务 的 所 有 资源 管理 髓 进行 通信 。 








口 应 用 程序 : 定义 事务 的 边界 ， 指 定 全 局 事务 中 的 操作 。 

在 MYSQL 数据 库 的 分 布 式 事务 中 ， 资 源 管理 器 就 是 MYSQL 数据 
库 ， 事 务 管理 器 为 连接 MySQL 服 务 句 的 客户 端 。 图 7-22 显 示 了 一 个 分 布 
式 事务 的 模型 。 











Application Program (Ap) 
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DELETE, 
SELECT 





Transaction Manager 
Resource Manager (TM) 


(RM’s) 








Two-Phase Commit 






图 7-22 分布 式 事务 模型 


分 布 式 事务 使 用 两 段 式 提交 (two-phase commit) 的 方式 。 在 第 一 
阶段 ， 所 有 参与 全 局 事务 的 节点 都 开始 准备 (PREPARE) ， 人 告诉 事务 








管理 器 它们 准备 好 提交 了 。 在 第 二 阶段 ， 事 务 管理 器 告诉 资源 管理 器 执 
行 ROLLBACK 还 是 COMMIT。 如 果 任 何 一 个 节 ry TË 提交 ， 则 所 
有 的 节点 都 被 告知 需要 回 滚 。 可 见 与 本 地 事务 不 同 的 是 ， 分 布 式 事务 需 
要 多 一 次 的 PREPARE 操 作 ， 待 收 到 所 有 节点 的 同意 信息 后 ， 再 进行 
COMMIT 或 是 ROLLBACK 操 作 。 


MySQL 数 据 库 XA 事 务 的 SQL 语法 如 下 : 














XA{START | BEGIN) xid[JOIN|RESUME] 
XA END xid[SUSPEND[FOR MIGRATE]] 
XA PREPARE x 

XA COMMIT siapoue PHASE] 

XA ROLLBACK x 

XA RECOVER 








在 单个 节点 上 运行 XA 事 务 的 例子 : 





mysql>XA START'a' 

Query OK,0 rows affected(8. 00 sec) 
mysql INSERT INTO z SELECT 11; 
Query OK,1 row affected(0.00 sec) 
Records: 1 Duplicates: 0 Warnings:0 
mysql>XA END'a 

Query OK,0 rows affected(0. 00 sec) 
mysql SX PREPARE 

Query OK,0 rows attected(o, 05 sec) 
mysql>XA RECOVER\G 

FOI IC TO TIO TOIT TO TO IO I 
formatID:1 

gtrid_length:1 
bqual_length:0 


1 row in set(0.00 sec) 
mysql>XA COMMIT'a 
Query OK,0 rows affected(0. 05 sec) 





在 单个 节点 上 运行 分 布 式 事务 没有 太 大 的 实际 意义 ， 但 是 要 在 
MySQL 数 据 库 的 合 令 下 演示 多 个 节点 参与 的 分 布 式 事务 也 是 行 不 通 
的 。 通 常 来 说 ， 都 是 通过 才 编 程 语言 来 完成 分 布 式 事务 的 操作 的 。 当 前 
Java 的 JTA (Java Transaction API) 可 以 很 好 地 文 持 MySQL 的 分 布 式 事 
务 ， 需 要 使 用 分 布 式 事务 应 该 认真 参考 其 API。 下 面 的 一 个 示例 显示 了 
如 何 使 用 JTA 来 调用 MySQL 的 分 布 式 事务 ， 就 是 前 面 所 举例 的 银行 转账 
的 例子 ， 代 码 如 下 ， 仅 供 参 考 : 




















import java.sql.Connection; 

import javax.sql.XAConnection; 

import javax.transaction.xa. 

import com.mysql. ;jdbc. jdbc2. oDpidnat: MysqlXADataSource; 
import java.sql.* 

class MyXid implements Xid 


{ 

public int formatId; 

public byte gtrid[]; 

public byte bqual[]; 

public Myxid(){ 

public MyXid(int formatId,byte gtrid[],byte bqual[]) 


this.formatId-formatId; 


this.gtrid-gtrid; 
this.bqual-bqual; 

a ies int getFormatId() 

ON formatId; 

public byte[]getBranchQualifier() 


return bqual; 


} 

public byte[]getGlobalTransactionId() 
{ 

return gtrid; 


} 


public class xa_demo{ 

public static MysqlXADataSource GetDataSource( 
String connstring, 

String user, 

String passwd){ 

try{ 

MysqlXADataSource ds-new MysqlXADataSource(); 
ds.setUrl(connsString); 

ds.setUser(user); 

ds.setPassword(passwd); 

return ds; 


catch(Exception e){ 
System.out.println(e.toString()); 

return null; 

} 

} 

public static void main(String[]Jargs){ 
String connStringi-"jdbc:mysql://192.168.24.43:3306/bank shanghai"; 
String connString2-"jdbc:mysql://192.168.24.166:3306/bank . 
beijing"; 

try{ 

MysqlXADataSource dsi- 
GetDataSource(connStringi,"peter","12345"); 
MysqlXADataSource ds2- 
GetDataSource(connString2, "david","12345"); 
XAConnection xaConni-ds1.getXAConnection(); 
XAResource xaResi-xaConni.getXAResource(); 
Connection conni-xaConni.getConnection(); 
Statement stmti-conni.createStatement(); 
XAConnection xaConn2-ds2.getXAConnection(); 
XAResource xaRes2-xaConn2.getXAResource(); 
Connection conn2-xaConn2.getConnection(); 
Statement stmt2-conn2.createStatement(); 
Xid xidi-new MyXid( 

100, 

new byte[](0x01j, 

new byte[]{0x02}); 

Xid xid2-new MyXid( 

100, 

new byte[](0x11j, 

new byte[]{0x12}); 

try{ 

xaRes1.start(xid1, XAResource. TMNOFLAGS) ; 
stmt1.execute(" 

UPDATE account SET money=money-10000 

WHERE user='david'" 

) 

xaRes1.end(xidi,XAResource.TMSUCCESS) ; 
xaRes2.start(xid2,XAResource.TMNOFLAGS) ; 
stmt2.execute(" 

UPDATE account SET money=money+10000 

WHERE user='mariah'" 

i 

xaRes2.end(xid2, XAResource. TMSUCCESS) ; 

int ret2=xaRes2.prepare(xid2); 

int reti-xaRes1.prepare(xid1); 
if(reti--XAResource.XA OK 

& &ret2--XAResource.XA OK)( 
xaRes1.commit(xid1, false); 
xaRes2.commit(xid2, false); 


jcatch(Exception e){ 
e.printStackTrace(); 


}catch(Exception e){ 
System.out.printin(e.toString()); 
} 

} 

} 








通过 参数 innodb_support_xa 可 以 查看 是 否 启 用 了 XA 事务 的 文 持 ( 默 
认为 ON) : 


mysql>SHOW VARIABLES LIKE'innodb support xa'*6; 
JOOOOOOOOOOOOOOOOOOOOIOOOOOOR] | p yy FAECES II ICI III I Ie 
Variable name:innodb support xa 

Value:ON 

1 row in set(0.01 sec) 


pM——————————————— M 


7.7.2 内 部 XA 事务 


之 前 讨论 的 分 布 式 事务 是 外 部 事务 ， 即 资源 管理 需 是 MYSQL 数据 
库 本 映 。 在 MySQL 数 据 库 中 还 存在 男 外 一 种 分 布 式 事务 ， 其 在 存储 引 
cll 又 或 者 在 存储 引擎 与 存储 引擎 之 间 ， 称 之 为 内 部 XA 事 

















BOA Th LAY A eB XA StS E F binlog 5 InnoDB #F tig Jl | A 由 
于 复制 的 需要 ， 因 此 目前 绝 大 多 数 的 数据 库 都 开启 了 binlog 功 能 。 在 事 
务 提 交 时 ， 先 写 二 进 制 日 志 ， 再 写 InnoDB 存 储 引擎 的 重 做 日 志 。 对 上 
述 两 个 操作 的 要 求 也 是 原子 的 ， 即 三 进 制 日 志和 重 做 日 志 必 须 同时 写 
入 。 若 三 进 制 日 志 先 写 了 ， 而 在 写 入 InnoDB 存 储 引 擎 时 发 生 了 宕 机 ， 
那么 slave 可 能 会 接收 到 master 传 过 去 的 二 进 制 日 志 并 执行 ， 最 终 导 致 了 
主 从 不 一 致 的 情况 。 如 图 7-23 所 示 。 
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图 7-23 宕 机 导致 replication 主 从 不 一 致 的 情况 





在 图 7-23 中 ， 如 果 执 行 完 中、 多 后 在 步骤 人 之 前 MySQL 数 据 库 发 生 
了 宕 机 ， 则 会 发 生 主 从 不 一 致 的 情况 。 为 了 解决 这 个 问题 ，MySQL 数 
据 库 在 binlog 与 InnoDB 存 储 引 擎 之 间 采 用 XA 事 务 。 当 事务 提交 时 ， 
InnoDB 存 储 引擎 会 先 做 一 个 PREPARE 操 作 ， 将 事务 的 xid 写 入 ， 接 着 进 
行 二 进 制 日 志 的 号 入 ， 如 图 7-24 所 示 。 如 果 在 mnoDB 存 储 引 擎 提交 前 ， 
MySQL 数 据 库 宕 机 了 ， 那 么 MySQL 数 据 库 在 重启 后 会 先 检 查 准 备 的 
UXID 事 务 是 否 已 经 提交 ， 若 没有 ， 则 在 存储 引擎 层 再 进行 一 次 提交 操 
TE. 
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图 7-24 MySQL 数据 库 通 过 内 部 XA 事 务 保 证 主 从 数据 一 臻 


relay log 





7.8 不 好 的 事务 习惯 


7.8.1 在 循环 中 提交 


开 肥 人员 非 常 喜 欢 在 循环 中 进行 事务 的 提交 ， 下 面 是 他 们 可 能 季 写 
的 一 个 存储 过 程 : 








CREATE PROCEDURE loadi(count INT UNSIGNED) 
BEGIN 


DECLARE s INT UNSIGNED DEFAULT 1 

DECLARE c CHAR(80)DEFAULT REPEAT(' a',80); 
WHILE s<=count DO 

INSERT INTO t1 SELECT NULL,c; 

COMMIT 

SET s-s*1; 

END WHILE; 





其 实 ， 在 上 述 的 例子 中 ， 是 否 加 上 提交 命令 COMMIT 并 不 关键 。 因 
为 InhnnoDB 存 储 引擎 默认 为 自动 提交 ， 所 以 在 上 述 的 存储 过 程 中 去 挥 
a LEERE FN. RATA DRAKA R AL 
问题: 








CREATE PROCEDURE load2(count INT UNSIGNED) 
BEGIN 


DECLARE s INT UNSIGNED DEFAULT 1 
DECLARE c CHAR(80)DEFAULT REPEAT (' a',80); 
WHILE s<=count DO 

INSERT INTO t1 SELECT NULL,c; 

SET s=s+1; 

END WHILE; 





不 论 上 面 哪个 存储 过 程 都 存在 一 个 问题 ， 当 发 生 错 误 时 ， 数 据 库 会 
停留 在 一 个 未 知 的 位 置 。 例 如 ， 用 户 需 要 插入 10 000 条 记录 ， 但 是 在 插 
入 5000 条 时 ， 发 生 了 错误 ， 这 时 前 5000 条 记录 己 经 存放 在 数据 库 中 ， 那 
应 该 怎么 处 理 呢 ?” 男 一 个 问题 是 性 能 问题 ， 上 面 两 个 存储 过 程 都 不 会 比 
下 而 的 丰 傅 过 各 load3 快 ， 因 为 下 面 的 存储 过 过 程 将 所 有 的 INSERT 都 放 在 











CREATE PROCEDURE load3(count INT UNSIGNED) 
BEGIN 


DECLARE s INT UNSIGNED DEFAULT 1 

DECLARE c CHAR(80)DEFAULT REPEAT] ' a',80); 
START TRANSACTION; 

WHILE s<=count DO 

INSERT INTO ti SELECT NULL,c; 

SET s-s*1; 

END WHILE; 

COMMIT; 

END; 


一 


比较 这 3 个 存储 过 程 的 执行 时 间 : 





mysql>CALL load1(10000); 
Query OK,0 rows affected(1 min 3.15 sec) 
mys Q1 TRUNCATE TABLE t1; 
ery OK,0 rows affected(0.05 sec) 
nys ql>CALL 10ad2(10000); 
ery OK,1 row affected(1 min 1.69 sec) 
nys q1>TRUNCATE TABLE t1; 
Query OK,0 rows affected(0.05 sec) 
mys ql>CALL 10ad3(10000); 
Query OK,0 rows affected(0.63 sec) 








显然 ， 第 三 种 方法 要 快 得 多 ! 这 是 因为 每 一 次 提交 都 要 写 一 次 重 做 
日 志 ， 存 储 过 程 1oad1 和 1load2 实 际 写 了 10 000 次 重 做 日 志文 件 ， 而 对 于 存 
储 过 程 load3 来 说 ， 实 际 只 写 了 1 次 。 可 以 对 第 二 个 存储 过 程 load2 的 调用 
进行 调整 ， 同 样 可 以 达到 存储 过 程 l0ad3 的 性 能 ， 如 : 





mysql- BEGIN; 

Query OK,0 rows affected(0.00 sec) 
mysql>CALL load2(10000); 

Query OK,1 row affected(0.56 sec) 
mys qL-CÓMMIT; 

Query OK,0 rows affected(0.03 sec) 





大 多 数 程序 员 会 使 用 第 一 种 或 第 二 种 方法 ， 有 人 可 能 不 知道 
InnoDB 存 储 引 擎 自动 提交 的 情况 ， 另 外 有 些 人 可 能 持 有 以 下 两 种 观 
点 : 首先 ， 在 他 们 曾经 使 用 过 的 数据 库 中 ， 对 事务 的 要 求 总 是 尽快 地 进 
行 释放 ， 不 能 有 长 时 间 的 事务 ; 其次， 他们 可 能 担心 存在 Oracle 数 据 库 
中 由 于 没有 足够 undo 产 生 的 Snapshot Too Old 的 经 典 问题 。MySQL 的 
InnoDB 存 储 引 擎 没有 上 述 两 个 问题 ， 因 此 程序 员 不 论 从 何 种 角度 出 
a EN 不 论 是 显 式 的 提交 还 
jg I AN 











7.8.2 ”使 用 目 动 提交 


自动 提交 并 不 是 一 个 好 的 习惯 ， 因 为 这 会 使 初级 DBA 容 易 犯 错 ， 另 
外 还 可 能 使 一 些 开 发 人 员 产 生 错 误 的 理解 ， 如 我 们 在 前 一 小 节 中 提 到 的 
循环 提交 问题 。MySQL 数 据 库 默 认 设置 使 用 上 自动 提交 Cautocommit) ， 
可 以 使 用 如 下 语句 来 改变 当前 自动 提交 的 方式 : 











mysql>SET autocommit-0; 
uery OK,0 rows affected(0.00 sec) 





也 可 以 使 用 START TRANSACTION，BEGIN 来 显 式 地 开启 一 个 事 
务 。 在 显 式 开局 事务 后 ， 在 默认 设置 下 《〈 即 参数 completion_type 等 于 
0) ，MySQL 会 自动 地 执行 SET AUTOCOMMIT=0 的 命令 ， 并 在 
COMMIT 或 ROLLBACK 结 束 一 个 事务 后 执行 SET AUTOCOMMIT=1. 


另外 ， 对 于 不 同 语言 的 API， 自 动 提交 是 不 同 的 。MySQL C API 默 
认 的 提交 方式 是 自动 提交 ， 而 MySQL Python API 则 会 自动 执行 SET 
AUTOCOMMIT=0， 以 禁用 自动 提交 。 因 此 在 选用 不 同 的 语言 来 编写 数 
据 库 应 用 程序 前 ， 应 该 对 连接 MySQL 的 API 做 好 研究 。 


我 认为 ， 在 编写 应 用 程序 开发 时 ， 最 好 把 事务 的 控制 权限 交 给 开发 
人 员 ， 即 在 程序 端 进 行事 务 的 开始 和 结束 。 同 时 ， 开 发 人 员 必 须 了 解 自 
动 提交 可 能 带 来 的 问题 。 我 曾经 见 过 很 多 开发 人 员 没 有 意识 到 目 动 提 交 
这 个 特性 ， 等 到 出 现 错误 时 应 用 就 会 遇 到 大 麻烦 。 














7.8.3 ”使 用 目 动 回 滚 


InnoDB 存 储 引 擎 支持 通过 定义 一 个 HANDLER 来 进行 自动 事务 的 回 
滚 操作 ， 如 在 一 个 存储 过 程 中 发 生 了 错误 会 自动 对 其 进行 回 滚 操作 。 
此 我 发 现 很 多 开发 人 员 喜 欢 在 应 用 程序 的 存储 过 程 中 使 用 自动 回 滚 操 
作 ， 例 如 下 面 所 示 的 一 个 存储 过 程 : 











CREATE PROCEDURE sp auto rollback demo() 
BEGIN 


DECLARE EXIT HANDLER FOR SQLEXCEPTION ROLLBACK; 
START TRANSACTION; 

INSERT INTO b SELECT 1; 

INSERT INTO b SELECT 2; 

INSERT INTO b SELECT 1; 

INSERT INTO b SELECT 3; 

COMMIT; 

END; 





存储 过 程 sp_auto_rollback_demo 首 先 定义 了 一 个 exit 类 型 的 
HANDLER， 当 捕获 到 错误 时 进行 回 深 。 结 构 如 下 : 





mysql>SHOW CREATE TABLE b\G; 

FOI ITT TOTTI TOI TO TO IO AC d. TOW >I IO II IR I II Ok 
Table:b 

Create Table:CREATE TABLE'b'( 

'a'int(11)NOT NULL DEFAULT'O', 

PRIMARY KEY('a') 

)ENGINE=InnoDB DEFAULT CHARSET-latini 

1 row in set(0.00 sec) 





因此 插入 第 二 个 记录 1 时 会 及 生 错 误 ， 但 是 因为 启用 了 自动 回 深 的 
操作 ， 因 此 这 个 存储 过 程 的 执行 结果 如 下 : 





mysql>CALL sp_auto_rollback_demo; 
Query OK,0 rows affected(0.06 sec) 
mysql>SELECT*FROM b; 

Empty set(0.00 sec) 








看 起 来 运行 没有 问题 ， 非 常 正常 。 但 是 ， 执 行 
sp_auto_rollback_demo 这 个 存储 过 程 的 结果 到 确 是 正确 的 还 是 错误 的 ? 
对 于 同样 的 存储 过 程 sp_auto_rollback_demo， 为 了 得 到 执行 正确 与 否 的 
结果 ， 开 发 人 员 可 能 会 进行 这 样 的 处 理 : 





CREATE PROCEDURE sp auto rollback demo() 
BEGIN 


DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; SELECT-1; END; 
START TRANSACTION; 

INSERT INTO b SELECT 1; 

INSERT INTO b SELECT 2; 

INSERT INTO b SELECT 1; 

INSERT INTO b SELECT 3; 


COMMIT; 
SELECT 1; 





当 发 生 错 误 时 ， 先 回 滚 然后 返回 -1， 表 示 运 行 有 错误 。 运 行 正 常 返 
回 值 1。 因 此 这 次 运行 的 结果 就 会 变 成 : 





mysql>CALL sp auto rollbac T demo()\G; 


FOCI IGG ICI ICICI] py CR Re TOR e IR eR Re I RIO 


set(0.04 sec) 
ered EERON b; 
Empty set(0.00 sec) 











看 起 来 用 户 可 以 得 到 运行 是 否 准 确 的 信息 。 但 问题 还 没有 最 终 解 
决 ， 对 于 开发 人 员 来 说 ， 重 要 的 不 仅 是 知道 有 友 生 了 错误 ， 而 是 发 生 了 什 
么 样 的 错误 。 因 此 自动 回 滚存 在 这 样 的 一 个 问题 。 


习惯 使 用 自动 回 滚 的 人 大 多 是 以 前 使 用 Microsoft SQL Server 数 据 库 
的 开发 人 员 。 在 Microsoft SQL Server 数 据 库 中 ， 可 以 使 用 SET XABORT 
ON 来 自动 回 深 一 个 事务 。 但 是 Microsoft SQL Server 数 据 库 不 仅 会 自动 
回 深 当 前 的 事务 ， 还 会 抛 出 异常 ， 开 发 人 员 可 以 捕获 到 这 个 异常 。 因 
n. Microsoft SQL Server 数 据 库 和 MySQL 数 据 库 在 这 方面 是 有 所 不 同 
js 


就 像 之 前 小 节 中 所 讲 到 的 ， 对 事务 的 BEGIN、COMMIT 和 
ROLLBACK 操 作 应 该 交 给 程序 端 来 完成 ， 存 储 过 程 需 要 完成 的 只 是 一 
个 逻辑 的 操作 ， 即 对 逻辑 进行 封装 。 下 面 演示 用 Python 语言 编写 的 程序 
调用 一 个 存储 过 程 sp_rollback_demo， 这 里 的 存储 过 程 sp_rollback_demo 
和 之 前 的 存储 过 程 sp_auto_rollback_demo 在 逻辑 上 完成 的 内 容 大 致 相 
同 : 























CREATE PROCEDURE sp_rollback_demo() 
BEGIN 


INSERT INTO b SELECT 1; 
INSERT INTO b SELECT 2; 
INSERT INTO b SELECT 1; 
INSERT INTO b SELECT 3; 





和 sp_auto_rollback_demo 存 储 过 程 不 同 的 是 ， 在 sp_rollback_demo 存 
储 过 程 中 去 掉 了 对 于 事务 的 控制 语句 ， 将 这 些 操作 都 交 由 程序 来 完成 。 
接着 来 看 test_demo.py 的 程序 源 代 码 : 





#!/usr/bin/env python 


#encoding=utf -8 

import MySQLdb 

try: 

conn= 

MySQLdb. connect (host="192.168.8.7",user="root", passwd="xx", db="test") 
cur=conn.cursor() 

cur.execute("SET autocommit=0" 
cur.execute("CALL sp rollback demo") 
cur.execute("COMMIT") 

except Exception,e: 
cur.execute("ROLLBACK" ) 

print e 





观察 运行 test_demo.py 这 个 程序 的 结果 : 





[root@nineyou0-43 一 ]#python test demo.py 
starting rollback 
(1062,"Duplicate entry'1'for key'PRIMARY'") 





在 程序 中 控制 事务 的 好 处 是 ， 用 户 可 以 得 知 发 生 错 误 的 原因 。 如 在 
上 上述 这 个 例子 中 ， 我 们 知道 是 因为 及 生 了 1062 这 个 错误 ， 错 误 的 提示 内 
容 是 Duplicate entry'l'for key'PRIMARY'， 即 发 生 了 主键 重复 的 错误 。 然 
后 可 以 根据 发 生 的 原因 来 进一步 调试 程序 。 





79 长 事务 


长 事务 (Long-Lived Transactions)， 顾 名 思 义 ， 就 是 执行 时 间 较 长 的 
事务 。 比 如 ， 对 于 银行 系统 的 数据 库 ， 每 过 一 个 阶段 可 能 需要 更 新 对 应 
账户 的 利 妃 。 如 果 对 应 账 志 的 数量 非常 大 ， 例 如 对 有 1 亿 用 户 的 表 


account， 需 要 执行 下 列 语句 : 





UPDATE account 
SET account_total=account_total+(1+interest_rate) 








这 时 这 个 事务 可 能 需要 非常 长 的 时 间 来 完成 。 可 能 需要 1 个 小 时 ， 

也 可 能 需要 4、5 个 小 时 ， 这 取决 于 数据 库 的 人 硬件 配置 。DBA 和 开发 人 员 
本 号 能 做 的 事情 非常 少 。 然 而 ， 由 于 事务 ACID 的 特性 ， 这 个 操作 被 封 
装 在 一 个 事务 中 完成 。 这 束 产 生 了 一 个 问题 ， 在 执行 过 程 中 ， 当 数据 库 
或 操作 系统 、 人 硬件 等 及 生 问 题 时 ， 重 新 开始 事务 的 代价 变 得 不 可 接受 。 
数据 库 需 要 回 滚 所 有 已 经 发 生 的 变化 ， 而 这 个 过 程 可 能 比 产生 这 些 变化 
的 时 间 还 要 长 。 因 此 ， 对 于 长 事务 的 问题 ， 有 时 可 以 通过 转化 为 小 批量 
(mini batch) 的 事务 来 进行 处 理 。 当 事务 发 生 错 误 时 ， 只 需要 回 深 一 部 分 
数据 ， 然 后 接着 上 次 已 完成 的 事务 继续 进行 。 


例如 ， 对 于 前 面 讨论 的 银行 利 县 计算 问题 ， 我 们 可 以 通过 分 解 为 小 
批量 事务 来 完成 ， 下 面 给 出 的 是 伪 代 码 ， 既 可 以 通过 程序 完成 ， 也 可 以 
通过 存储 过 程 完成 : 




















void ComputeInterest (double interest_rate){ 

long last account done,max account no,log size; 

int batch_size=100000; 

EXEC SQL SELECT COUNT(*)INTO log size FROM batchcontext; 
if(SQLCODE!-0| | log_size==0) { 

EXEC SQL DROP TABLE IF EXISTS batchcontext; 

EXEC SQL CREATE TABLE batchcontext(last account done BIGINT); 
last account done-0; 

INSERT INTO batchcontext SELECT 0; 


} 
else{ 
EXEC SQL SELECT last_account_no 
INTO last_account_done 

FROM batchcontext; 


} 

EXEC SQL SELECT COUNT(*)INTO max_account_no 

FROM account LOCK IN SHARE MODE; 
WHILE(last_account_no<max_account_no) { 

EXEC SQL START TRANSACTION; 

EXEC SQL UPDATE account 

SET account_total=account_total*(1+interest_rate) ; 
WHERE account_no 

BETWEEN last_account_no 

AND last_account_notbatch_size; 

EXEC SQL UPDATE batchcontext 

SET last_account_done=last_account_done+batch_size; 
EXEC SQL COMMIT WORK; 
last_account_done=last_account_done+batch_size; 





} 
} 


EL 





上 述 代码 将 一 个 需要 处 理 1 亿 用 户 的 大 事务 分 解 为 每 次 处 理 10 万 用 
户 的 小 事务 ， 通 过 批量 处 理 小 事务 来 完成 大 事务 的 逻辑 。 每 完成 一 个 小 
事务 ， 将 完成 的 结果 存放 在 batchcontext 表 中 ， 表 示 已 完成 批量 事务 的 最 
大 账号 ID。 知 事务 在 运行 过 程 中 产生 问题 ， 需 要 重 做 事务 ， 可 以 从 这 个 
已 完成 的 最 大 事务 ID 继续 进行 批量 的 小 事务 ， 这 样 重 新 开局 事务 的 代价 
束 显 得 比较 低 ， 也 更 容易 让 用 户 接 受 。batchcontext 表 的 男 外 一 个 好 处 
是 ， 在 长 事务 的 执行 过 程 中 ， 用 户 可 以 知道 现在 大 概 已 经 执行 到 了 哪个 
阶段 。 比 如 一 共有 1 亿 条 的 记录 ， 现 在 表 batchcontext 中 最 大 的 账号 ID 为 
4000 万 ， 也 就 是 说 这 个 大 事务 大 概 完成 了 40% 的 工作 。 


这 里 还 有 一 个 小 地 方 需 要 注意 ， 在 从 表 account 中 取得 
max_account_no 时 ， 人 为 地 加 上 了 一 个 共享 锁 ， 以 保证 在 事务 的 处 理 过 
程 中 ， 没 有 其 他 的 事务 可 以 来 更 新 表 中 的 数据 ， 这 是 有 意义 的 ， 并 且 也 
是 非常 有 必要 的 操作 。 
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在 这 一 章 中 我 们 了 解 了 InnoDB 人 存储 引擎 管理 事务 的 许多 方面 。 了 
解 了 事务 如 何 工作 以 及 如 何 使 用 事务 ， 这 在 任何 数据 库 中 对 于 正确 实现 
A 此 外 ， 事 务 是 数据 库 区 别 于 文件 系统 的 一 个 关键 特 


事务 必须 遵循 ACID 特性 ， 即 Atomicity( 原 子 性 )、Consistency( 一 臻 
性 )、Isolation( 隅 离 性 ) 和 Durability( 持 和 久 性 )。 隔 离 性 通过 第 6 章 介 绍 过 的 
锁 来 完成 ; 原子 性 、 一 致 性 、 隔 离 性 通过 redo 和 undo 来 完成 。 通 过 对 
redo 和 undo 的 了 解 ， 可 以 进一步 明白 事务 的 工作 原理 以 及 如 何 更 好 地 使 
用 事务 。 接 着 我 们 讲 到 了 InnoDB 存 储 引 敬文 持 的 四 个 事务 隔离 级 别 ， 
知道 了 InnoDB 存 储 引 擎 的 默认 事务 隔离 级 别 是 REPEATABLE READ 
的 ， 不 同 于 SQL 标准 对 于 事务 隅 离 级 别 的 要 求 ，ImnoDB 存 储 引 擎 在 
REPEATABLE READ 隔 离 级别 下 束 可 以 达到 3? 的 隔离 要 求 。 


本 章 最 后 讲解 了 操作 事务 的 SQL 语句 以 及 怎样 在 应 用 程序 中 正确 使 
用 事务 。 在 默认 配置 下，MySQL 数 据 库 总 是 自动 提交 的 一 如果 不 知 
道 这 点 ， 可 能 会 带 来 非常 不 好 的 结果 。 此 外 ， 在 应 用 程序 中 ， 最 好 的 做 
法 是 把 事务 的 START TRANSACTION, COMMIT. ROLLBACK 
给 程序 端 来 完成 ， 而 不 是 在 存储 过 程 内 完成 。 在 完整 了 解 了 InnoDB 存 
储 引 擎 事务 机 制 后 ， 相 信和 你 可 以 开发 出 一 个 很 好 的 企业 级 MySQL 
InnoDB 数 据 库 应 用 了 。 

















"BOR ”备份 与 恢复 


对 于 DBA 来 说 ， 数 据 库 的 备份 与 恢复 是 一 项 最 基本 的 操作 与 工作 。 
企 意 外 情况 下 《如 服务 器 宕 机 、 磁 盘 损 坏 、RAID 卡 损坏 等 ) 要 保证 数 
据 不 丢失 ， 或 者 是 最 小 程度 地 丢失 ， 每 个 DBA 应 该 每 时 每 刻 关 心 所 负责 
的 数据 库 备 份 情况 。 


本 章 主要 介绍 对 InnoDB 存 储 引 擎 的 备份 ， 应 该 知道 MySQL 数 据 库 
提供 的 大 多 数 工具 (如 mysqldump、ibbackup、replication ) 都 能 很 好 地 
完成 备份 的 工作 ， 当 然 也 可 以 通过 第 三 方 的 一 些 工 具 来 完成 ， 如 
xtrabacup、LVM 快 照 备 份 等 。DBA 应 该 根据 自己 的 业务 要 求 ， 设 计 出 
损失 最 小 、 对 于 数据 库 影 响 最 小 的 备份 策略 。 














8.1. 备份 与 恢复 概述 


可 以 根据 不 同 的 类 型 来 划分 备份 的 方法 。 根 据 备份 的 方法 不 同 可 以 
将 备份 分 为 : 


DHot Backup 〈 热 备 ) 








DCold Backup (44) 
DWarm Backup ( 温 备 ) 


Hot Backup 是 指数 据 库 运行 中 直接 备份 ， 对 正在 运行 的 数据 库 操作 
没有 任何 的 影响 。 这 种 方式 在 MySQL 官 方 手册 中 称 为 Online 
Backup 〈 在 线 备 份 ) 。Cold ” Backup 是 指 备份 操作 是 在 数据 库 停 止 的 情 
况 下 ， 这 种 备份 最 为 简单 ， 一 般 只 需要 复制 相关 的 数据 库 物 理 文件 即 
可 。 这 种 方式 在 MySQL 官 方 手册 中 称 为 Offline Backup CAREM) 。 
Warm Backup 备 份 同样 是 在 数据 库 运 行 中 进行 的 ， 但 是 会 对 当前 数据 库 
的 操作 有 所 影响 ， 如 加 一 个 全 局 读 锁 以 保证 备份 数据 的 一 致 性 。 


按照 备份 后 文件 的 内 容 ， 备 份 又 可 以 分 为 : 
QUE f p) 
口 裸 文件 备份 


在 MySQL 数 据 库 中 ， 逻 辑 备份 是 指 备份 出 的 文件 内 容 是 可 读 的 ， 
一 般 是 文本 文件 。 内 容 一 般 是 由 一 条 条 SQL 语句 ， 或 者 是 表 内 实际 数据 
组 成 。 如 mysqldump 和 SELECT*INTO OUTFILE 的 方法 。 这 类 方法 的 好 
处 是 可 以 观察 导出 文件 的 内 容 ， 一 般 适 用 于 数据 库 的 升级 、 迁 移 等 工 
作 。 但 其 缺点 是 恢复 所 需要 的 时 间 往 往 较 长 。 


裸 文件 备份 是 指 复制 数据 库 的 物理 文件 ， 既 可 以 是 在 数据 库 运 行 中 
的 复制 (如 ibbackup、xtrabackup 这 类 工具 ) ， 也 可 以 是 在 数据 库 停 止 运 
a a 




















右 按 照 备 份 数据 库 的 内 容 来 分 ， 备 份 又 可 以 分 为 : 


口 完 全 备份 
口 增 量 备份 
口 日 志 备 份 


完全 备份 是 指 对 数据 库 进 行 一 个 完整 的 备份 。 增 量 备份 是 指 在 上 次 
完全 备份 的 基础 上 ， 对 于 更 改 的 数据 进行 备份 。 日 志和 备份 主 要 是 指 对 
MySQL 数 据 库 二 进 制 日 志 的 备份 ， 通 过 对 一 个 完全 备份 进行 二 进 制 日 
志 的 重 做 (replay) 来 完成 数据 库 的 point-in-time 的 恢复 工作 。MySQL 数 
据 库 复 制 Creplication ) 的 原理 就 是 异步 实时 地 将 二 进 制 日 志 重 做 传送 
并 应 用 到 从 (slave/standby〉 数据 库 。 


对 于 MySQL 数 据 库 来 说 ， 官 方 没 有 提供 真正 的 增 量 备 份 的 方法 ， 

大 部 分 是 通过 二 进 制 日 志 完 成 增 量 备份 的 工作 。 这 种 备份 较 之 真正 的 增 
量 备份 来 说 ， 效 率 还 是 很 低 的 。 假 设 有 一 个 100GB 的 数据 库 ， 要 通过 二 
进 制 日 志 完 成 备份 ， 可 能 同一 个 页 需要 执行 多 次 的 SQL 语句 完成 重 做 的 
工作 。 但 是 对 于 真正 的 增 量 备份 来 说 ， 只 需要 记录 当前 每 页 最 后 的 检查 
点 的 LSN， 如 果 大 于 之 前 全 备 时 的 LSN， 则 备份 该 页 ， 否 则 不 用 备份 ， 
这 大 大 加 快 了 备份 的 速度 和 恢复 的 时 间 ， 同 时 这 也 是 xtrabackup 工 具 增 
量 备份 的 原理 。 


此 外 还 需要 理解 数据 库 备 份 的 一 致 性 ， 这 种 备份 要 求 在 备份 的 时 候 
数据 在 这 一 时 间 扣 上 是 一 致 的 。 举 例 来 说 ， 在 一 个 网 络 游戏 中 有 一 个 玩 
家 购买 了 道具 ， 这 个 事务 的 过 程 是 : 先 扣除 相应 的 金钱 ， 然 后 向 其 装备 
表 中 插入 道具 ， 确 保 扣 强 和 得 到 道具 是 互相 一 致 的 。 人 否则 ， 在 恢复 时 ， 
可 能 出 现金 钱 被 扣除 了 而 装备 丢失 的 问题 。 


对 于 InnoDB 存 储 引 擎 来 说 ， 因 为 其 支持 MVCC 功 能 ， 因 此 实现 一 致 
的 备份 比较 简单 。 用 户 可 以 先 开启 一 个 事务 ， 然 后 导出 一 组 相关 的 表 ， 
最 后 提交 。 当 然 用 户 的 事务 隔离 级 别 必须 设置 为 REPEATABLE 
READ， 这 样 的 做 法 就 可 以 给 出 一 个 完美 的 一 致 性 备份 。 然 而 这 个 方法 
的 前 提 是 需要 用 户 正 确 地 设计 应 用 程序 。 对 于 上 述 的 购买 道具 的 过 程 ， 
不 可 以 分 为 两 个 事务 来 完成 ， 如 一 个 完成 扣 费 ， 一 个 完成 道具 的 购买 。 
和 若 备 份 这 时 发 生 在 这 两 者 之 间 ， 则 由 于 逻辑 设计 的 问题 ， 导 致 备份 出 的 
数据 依然 不 是 一 致 的 。 


对 于 mysqldump 备 份 工具 来 说 ， 可 以 通过 添加 --single-transaction 选 





























项 获得 InnoDB 存 储 引 擎 的 一 致 性 备份 ， 原 理 和 之 前 所 说 的 相同 。 需 要 
了 解 的 是 ， 这 时 的 备份 是 在 一 个 执行 时 间 很 长 的 事务 中 完成 的 。 另 外 ， 
对 于 InnoDB 存 储 引 擎 的 备份 ， 务 必 加 上 --single-transaction 的 选项 〈 虽 然 
是 mysqldump 的 一 个 可 选 选项 ， 但 是 我 找 不 出 任何 不 加 的 理由 ) 。 


同时 我 建议 每 个 公司 要 根据 自己 的 备份 策略 编写 一 个 备份 的 应 用 程 
序 ， 这 个 程序 可 以 方便 地 设置 备份 的 方法 及 监控 备份 的 结果 ， 并 且 通 过 
第 三 方 接口 实时 地 通知 DBA， 这 样 才 能 真正 地 做 到 24x7 的 备份 监控 。 久 
游 网 开发 过 一 套 DAO (Database Admin Online) 系统 ， 这 套 系 统 完全 由 
DBA 开 发 完成 ， 整 个 平台 用 Python 语言 编写 ，Web 操 作 界 面 采 用 
Django。 通 过 这 个 系统 DBA 可 以 方便 地 对 几 百 台 MySQL 数 据 库 服务 占 
进行 备份 ， 同 时 得 看 备份 完成 后 备份 文件 的 状态 。 之 后 DBA 又 对 其 进行 
了 扩展 ， 不 仅 可 以 完成 备份 的 工作 ， 也 可 以 实时 监控 数据 库 的 状态 、 系 
统 的 状态 和 硬件 的 状态 ， 当 发 生 问 题 时 ， 通 过 飞信 接口 在 第 一 时 间 以 短 
信 的 方式 告知 DBA。 


最 后 ， 任 何 时 候 都 需要 做 好 远程 寞 地 备份 ， 也 就 是 容 灾 的 防范 。 只 
古 同 一 机 房 的 两 台 服 务 器 的 备份 是 远 远 不 够 的 。 我 曾经 遇 到 的 情况 是 ， 
公司 在 2008 年 的 汉 川 地 震中 友 生 一 个 机 房 可 能 被 淹 的 的 情况 ， 这 时 远程 
异地 备份 显得 就 全 关 重 要 了 。 
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通常 DBA 会 写 一 个 脚本 来 进行 冷 备 的 操作 ，DBA 可 能 还 会 对 备份 
完 的 数据 库 进 行 打包 和 压缩 ， 这 都 并 不 是 难事 。 关 键 在 于 不 要 遗漏 原本 
需要 备份 的 物理 文件 ， 如 共享 表 空 间 和 重 做 日 志文 件 ， 少 了 这 些 文件 可 
能 数据 库 都 无 法 启动 。 另 外 一 种 经 常 发 生 的 情况 是 由 于 磁盘 空间 已 满 而 
导致 的 备份 失败 ，DBA 可 能 习惯 性 地 认为 运行 脚本 的 备份 是 没有 问题 
的 ， 少 了 检验 的 机 制 。 

正如 前 面 所 说 的 ， 在 同一 台 机 器 上 对 数据 库 进行 冷 备 是 远 远 不 够 
的 ， 至 少 还 需要 将 本 地 产生 的 备份 存放 到 一 全 远程 的 服务 器 中 ， 确 保 不 
会 因为 本 地 数据 库 的 宕 机 而 影响 备份 文件 的 使 用 。 

冷 备 的 优点 是 : 

口 备份 简单 ， 只 要 复制 相关 文件 即 可 。 

口 备份 文件 易于 在 不 同 操 作 系 统 ， 不 同 MySQL 版 本 上 进行 恢复 。 

口 恢 复 相当 简单 ， 只 需要 把 文件 恢复 到 指定 位 置 即 可 。 

口 恢复 速度 快 ， 不 需要 执行 任何 SQL 语句 ， 也 不 需要 重建 索引 。 

冷 备 的 缺点 是 : 


DInnoDB 人 存储 引擎 冷 备 的 文件 通常 比 逻 辑 文件 大 很 多 ， 因 为 表 空 
间 中 存放 着 很 多 其 他 的 数据 ， 如 undo 段 ， 插 入 缓冲 等 信息 。 


口 冷 备 也 不 总 是 可 以 轻易 地 跨 平 合 。 操 作 系 统 、MVYSQL 的 版 本 、 
文件 大 小 写 敏 感 和 浮 点 数 格式 都 会 成 为 问题 。 




















8.3 EHE 
8.3.1 mysqldump 


mysqldump 备 份 工具 最 初 由 Igor Romanenko 编 写 完 成 ， 通 常用 来 完 
RFT (dump) 数据 库 的 备份 及 不 同 数 据 库 之 间 的 移植 ， 如 从 MySQL 
低 厂 本 数据 库 升 级 到 MySQL 高 版 本 数据 库 ， 又 或 者 从 MySQL 数 据 库 移 
植 到 Oracle、Microsoft SQL Server 数 据 库 等 。 


mysqldump 的 语法 如 下 : 





shell>mysqldump[arguments]>fle_name 





如 果 想 要 备份 所 有 的 数据 库 ， 可 以 使 用 --all-databases 选 项 : 





shell>mysqldump- -all-databases>dump.sql 





如 果 想 要 备份 指定 的 数据 库 ， 可 以 使 用 --databases 选 项 : 





shell>mysqldump--databases dbi db2 db3>dump.sql 





如 末 想 要 对 test 这 个 架构 进行 备份 ， 可 以 使 用 如 下 语句 : 





[root@xen-server~]#mysqldump--single-transaction test>test_backup.sql 





上 述 操作 产生 了 一 个 对 test 架 构 的 备份 ， 使 用 --single-transaction 选 项 
来 保证 备份 的 一 臻 性。 备份 出 的 test_backup.sql 是 文本 文件 ， 通 过 文本 查 
看 命令 cat 就 可 以 得 到 文件 的 内 容 : 





[root@xen-server~]#cattest_backup.sql 
--MySQL dump 10.13 Distrib 5.5.1-m2,for unknown-linux-gnu(x86 64) 


--Host:localhost Database:test 


--Server version 5.5.1-m2-log 
--Table structure for table'a' 
DROP TABLE IF EXISTS'a'; 


/*140101 SETQsaved cs client-QQcharacter set client*/; 
/*140101 SET character set client-utf8*/; 


CREATE TABLE'a'( 

'b'int(11)NOT NULL DEFAULT'O', 

PRIMARY KEY('b' 

)ENGINE=InnoDB DEFAULT CHARSET-latini; 

/*140101 SET character set client-Qsaved cs client*/; 


--Dumping data for table'a' 


LOCK TABLES'a'WRITE; 

/*140000 ALTER TABLE'a'DISABLE KEYS*/; 
INSERT INTO'a'VALUES(1), (2), (4), (5); 
/*140000 ALTER TABLE'a'ENABLE KEYS*/; 
UNLOCK TABLES; 


--Table structure for table'z' 


DROP TABLE IF EXISTS'z'; 

/*140101 SETQsaved cs client-QQcharacter set client*/; 
/*140101 SET character set client-utf8*/; 

CREATE TABLE'z'( 

'a'int(11)DEFAULT NULL 

JENGINE-InnoDB DEFAULT CHARSET-latini; 

/*140101 SET character set client-Qsaved cs client*/; 


--Dumping data for table'z' 


LOCK TABLES'z WRITE; 

/*140000 ALTER TABLE'z'DISABLE KEYS*/; 
INSERT INTO'z' VALUES(1), (1) ; 

/*140000 ALTER TABLE'z'ENABLE KEYS*/; 
UNLOCK TABLES; 


--Dump completed on 2010-08-03 13:36:17 





可 以 看 到 ， 备 份 出 的 文件 内 容 就 是 表 结 构 和 数据 ， 所 有 这 些 都 是 用 
SQL 语句 方式 表示 。 文 件 开始 和 结束 的 注释 部 分 是 用 来 设置 MySQL 数 所 
库 的 各 项 参数 ， 一 般 用 来 使 还 原 工 作 更 有 效 和 准确 地 进行 。 之 后 的 部 分 
先是 CREATE TABLE 语 句 ， 接 着 就 是 INSERT 的 SQL 语句 了 。 


mysqldump 的 参数 选项 很 多 ， 可 以 通过 使 用 mysqldump--help 命 令 来 
得 看 所 有 的 参数 ， 有 些 参数 有 缩写 形式 ， 如 --lock-tables 的 缩写 形式 -]。 
这 里 列举 一 些 比 较 重 要 的 参数 。 


口 --single-transaction: 在 备份 开始 前 ， 先 执行 START 
TRANSACTION 人 命令， 以 此 来 获得 备份 的 一 致 性 ， 当 前 该 参数 只 对 
InnoDB 存 储 引 擎 有 效 。 当 启用 该 参数 并 进行 备份 时 ， 确 保 没 有 其 他 任 
何 的 DDL 语 名 执行 ， 因 为 一 致 性 读 并 不 能 隔离 DDL 操 作 。 


口 --lock-tables〈-1) : 在 备份 中 ， 依 次 锁 住 每 个 架构 下 的 所 有 表 。 
一 般 用 于 MyISAM 存 储 引 擎 ， 当 备份 时 只 能 对 数据 库 进 行 读 取 操 作 ， 不 
过 备份 依然 可 以 保证 一 致 性 。 对 于 ImnoDB 存 储 引 擎 ， 不 需要 使 用 该 参 
数 ， 用 --single-transaction 即 可 。 并 且 --lock-tables 和 --single-transaction 是 
Hk Cexclusive) 的 ， 不 能 同时 使 用 。 如 果 用 户 的 MySQL 数 据 库 中 ， 既 
有 MYVyISAM 存 储 引 擎 的 表 ， 又 有 InnoDB 存 储 引 擎 的 表 ， 那 么 这 时 用 户 的 
选择 只 有 --lock-tables 了 。 此 外 ， 正 如 前 面 所 说 的 那样 ，--lock-tables 选 项 
是 依次 对 每 个 架构 中 的 表 上 锁 的 ， 因 此 只 能 保证 每 个 架构 下 表 备 份 的 一 
致 性 ， 而 不 能 保证 所 有 架构 下 表 的 一 致 性 。 




















O--lock-all-tables (-x) : 在 备份 过 程 中 ， 对 所 有 架构 中 的 所 有 表 
上 锁 。 这 个 可 以 避免 之 前 说 的 --lock-tables 参 数 不 能 同时 锁 住 所 有 表 的 问 


题 。 


L1--add-drop-database: 在 CREATE DATABASE 前 先 运 行 DROP 
DATABASE。 这 个 参数 需要 和 --all-databases 或 者 --databases 选 项 一 起 使 
用 。 在 默认 情况 下 ， 导 出 的 文本 文件 中 并 不 会 有 CREATE 
DATABASE， 除 非 指 定 了 这 个 参数 ， 因 此 可 能 会 看 到 如 下 的 内 容 : 





[root@xen-server~]#mysqldump--single-transaction--add-drop-database--databases test>test_backup.sql 
[root@xen-server~]#cat test backup.sq 
--MySQL dump 10.13 Distrib 5.5.1-m2,for unknown-linux-gnu(x86 64) 


--Current Database: 'test' 
/*140000 DROP DATABASE IF EXISTS'test'*/; 


CREATE DATABASE/*!32312 IF NOT EXISTS*/'test'/*!40100 DEFAULT CHARACTER SET latini*/; 
USE'test'; 





L]--master-data[-value]: 通过 该 参数 产生 的 备份 转 存 文件 主要 用 来 
建立 一 个 replication。 当 value 的 值 为 1 时 ， 转 存 文 件 中 记录 CHANGE 
MASTER 语 句 。 当 value 的 值 为 2 时 ，CHANGE MASTER 语 名 被 写 出 SQL 
E. NND value 的 值 为 空 。 当 value 值 为 1 时 ， 在 备份 文件 中 
会 看 到 : 





[root@xen-server~]#mysqldump--single-transaction--add-drop-database--master-data=1--databases test>test_backup.sql 
[root@xen-server~]#cat test backup.sql 
--MySQL dump 10.13 Distrib 5.5.1-m2,for unknown-linux-gnu(x86 64) 


--Host:localhost Database:test 
--Server version 5.5.1-m2-log 
--Position to start replication or point-in-time recovery from 


CHANGE MASTER TO MASTER LOG FILE-'xen-server-bin.000006',MASTER LOG P0S-8095; 





当 value 为 2 时 ， 在 备份 文件 中 会 看 到 CHANGE MASTER 语 句 被 注释 
了 : 





[root@xen-server ~ ]4mysqldump--single-transaction--add-drop-database--master-data-2--databases test>test_backup.sql 
[root@xen-server~]#cat test_backup.sql 
--MySQL dump 10.13 Distrib 5.5.1-m2, for unknown-linux-gnu(x86 64) 


--Host:localhost Database:test 


--Server version 5.5.1-m2-log 


--Position to start replication or point-in-time recovery from 


口 --master-data 会 自动 忽略 --lock-tables 选 项 。 如 果 没 有 使 用 --single- 
transaction 选 项 ， 则 会 自动 使 用 --lock-all-tables 选 项 。 


O--events (-E) : 备份 事件 调度 器 。 

口 --routines C-RO : 备份 存储 过 程 和 函数 。 

口 --triggers: 备份 触发 器 。 

口 --hex-blob: 将 BINARY、VARBINARY、BLOG 和 BIT 列 类 型 备 
份 为 十 六 进 制 的 格式 。mysqldump 导 出 的 文件 一 般 是 文本 文件 ， 但 是 如 


果 导 出 的 数据 中 有 上 述 这 些 类 型 ， 在 文本 文件 模式 下 可 能 有 些 字符 不 可 
见 ， 大 添加 --hex-blob 选 项 ， 结 果 会 以 十 六 进 制 的 方式 显示 ， 如 : 














[root@xen-server~]#mysqldump--single-transaction--add-drop-database--master-data=2--no-autocommit--databases test3> 
test3_backup.sql 

[root@xen-server~]#cat test3 backup.sql 

--MySQL dump 10.13 Distrib 5.5.1-m2,for unknown-linux-gnu(x86 64) 


--Host:localhost Database:test3 


--Server version 5.5.1-m2-log 


LOCK TABLES'a'WRITE; 

/*140000 ALTER TABLE'a'DISABLE KEYS*/; 
setautocommit-0; 

INSERT INTO'a'VALUES(0x61000000000000000000) ; 
/*140000 ALTER TABLE'a'ENABLE KEYS*/; 

UNLOCK TABLES; 





可 以 看 到 ， 这 里 用 0x61000000000000000000 的 十 六 进 制 的 格式 来 导 
出 数据 。 


口 --tab=path (-T path) : 产生 TAB 分 割 的 数据 文件 。 对 于 每 张 表 ， 
mysqldump 创 建 一 个 包含 CREATE TABLE 语 名 的 table_name.sql 文 件 ， 和 
包含 数据 的 tbl_name.txt 文 件 。 可 以 使 用 --fields-terminated-by=...，-- 
fields-enclosed-by=..., --fields-optionally-enclosed-by=..., --fields-escaped- 
by=.…，--lines-terminated-by=.… 来 改变 默认 的 分 割 符 、 换 行 符 等 。 如 : 





[root@xen-server test]&mysqldump--single-transaction--add-drop-database--tab-"/usr/local/mysql/data/test"test 
[root@xen-server test]4ls-lh 
total 244K 


--Server version 5.5.1-m2-lo 

/*140101 SETQOLD CHARACTER SET CLIENT-QQCHARACTER SET CLIENT*/; 
/*140101 SETQOLD CHARACTER SET RESULTS-QQCHARACTER SET RESULTS*/; 
/*140101 SET@OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION*/; 


/*140101 SET NAMES utf8*/; 

/*140103 SETQOLD TIME ZONE-QQTIME ZONE*/; 

/*140103 SET TIME ZONE-'-400:00'*/; 

/*140101 SETQOLD SQL MODE-QQSQL MODE, SQL MODE-''*/; 

/*140111 SETQOLD SQL NOTES-QQSQL NOTES,SQL NOTES-0*/; 

--Table structure for table'a' 

DROP TABLE IF EXISTS'a'; 

/*140101 SETQsaved cs client-QQcharacter set client*/; 
/*140101 SET character set client-utf8*/; 

CREATE TABLE'a'( 

'b'int(11)NOT NULL DEFAULT'O', 

PRIMARY KEY('b') 

)ENGINE=InnoDB DEFAULT CHARSET-latini; 

/*140101 SET character set client-Qsaved cs client*/; 

/*140103 SET TIME ZONE-QOLD TIME ZONE*/; 

/*140101 SET SQL MODE-QOLD SQL MODE*/; 

/*140101 SET CHARACTER SET CLIENT-QOLD CHARACTER SET CLIENT*/; 
/*140101 SET CHARACTER SET RESULTS-QOLD CHARACTER SET RESULTS*/; 
/*140101 SET COLLATION CONNECTION-QOLD COLLATION CONNECTION*/; 
/*140111 SET SQL NOTES-QOLD SQL NOTES*/; 

--Dump completed on 2010-08-03 15:36:56 

[root@xen-server test]#cat a.txt 


ON 





我 发 现 大 多 数 DBA 喜 欢 用 SELECT...INTO OUTFILE 的 方式 来 导出 





张 表 ， 但 是 通过 mysqldump 一 样 可 以 完成 工作 ， 而 且 可 以 一 次 完成 多 


张 表 的 导出 ， 并 且 实 现 导 出 数据 的 一 致 性 。 


口 --where='where_condition' (-w'where condition) : 导出 给 定 条 件 


的 数据 。 如 导出 b 染 构 下 的 表 a， 并 且 表 a 的 数据 大 于 2: 





root@xen-server bin]#mysqldump--single-transaction--where= est a>a.sq 
tQ bin]# ld ingle-t ti h "b>2'test a> 1 


[root@xen-server bin]#cat a.sql 
--MySQL dump 10.13 Distrib 5.5.1-m2, for unknown-linux-gnu(x86 64) 


--Host:localhost Database:test 


--Server version 5.5.1-m2-log 


--Dumping data for table'a' 

- -WHERE :b>2 

LOCK TABLES'a'WRITE; 

/*140000 ALTER TABLE'a'DISABLE KEYS*/; 
INSERT INTO'a'VALUES(4), (5); 

/*140000 ALTER TABLE'a'ENABLE KEYS*/; 
UNLOCK TABLES; 

/*140103 SET TIME ZONE-QOLD TIME ZONE*/; 


es | 


8.3.2 SELECT..INTO OUTFILE 


SELECT...INTO 语 句 也 是 一 种 逻辑 备份 的 方法 ， 更 准确 地 说 是 导出 
一 张 表 中 的 数据 。SELECT...INTO 的 语法 如 下 : 





SELECT[column 1],[column 2]... 
INTO 


OUTFILE'file name' 

[ {FIELDS | COLUMNS) 

[TERMINATED BY'string'] 
[[OPTIONALLY]ENCLOSED BY'char'] 
[ESCAPED BY'char'] 


] 

[LINES 

[STARTING BY'string'] 
[TERMINATED BY'string'] 


] 
FROM TABLE WHERE...... 





其 中 FIELDS[TERMINATED BY'string] 表 示 每 个 列 的 分 隔 符 ， 
[[OPTIONALLY]ENCLOSED BY'char] 表 示 对 于 字符 串 的 包含 符 ， 
[ESCAPED BY'char] 表 示 转 义 符 。[STARTING BY'string] 表 示 每 行 的 开 
始 符号 ，TERMINATED ByY'string' 表 示 每 行 的 结束 符号 。 如 果 没 有 指定 
任何 的 FIELDS 和 LINES 的 选项 ， 默 认 使 用 以 下 的 设置 : 








FIELDS TERMINATED BY'Nt'ENCLOSED BY''ESCAPED BY'NN' 
LINES TERMINATED BY'Nn'STARTING BY'' 





file_name 表 示 导 出 的 文件 ， 但 文件 所 在 的 路 径 的 权限 必须 是 
mysql : mysql 的 ， 否 则 MySQL 会 报 没有 权限 导出 : 





mysql>select*into outfile'/root/a.txt'from a; 
ERROR 1(HY9090):Can't create/write to file'/root/a.txt'(Errcode:13) 








右 已 经 存在 该 文件 ， 则 同样 会 报错 : 





[root@xen-server~]#mysql test-e"select*into outfile'/home/mysql/a.txt'fields terminated by','from a" 
ERROR 1086(HY000)at line 1:File'/home/mysql/a.txt'already exists 





查看 通过 SELECT INTO 导 出 的 表 a 文 件 : 





mysql>select*into outfile'/home/mysql/a.txt'from a; 
Query OK,3 rows affected(0.02 sec) 
mysql>quit 


ye 
[root@xen-server~ ]#cat/home/mysql/a.txt 
1a 


wn 
oc 





可 以 发 现 ， 默 认 导出 的 文件 是 以 TAB 进行 列 分 割 的 ， 如 果 想 要 使 用 
其 他 分 割 符 ， 如 “，”， 则 可 以 使 用 FIELDS TERMINATED BY'string' 选 
项 ， 如 : 





[root@xen-server~]#mysql test-e"select*into outfile'/home/mysql/a.txt'fields terminated by','from a"; 
[root@xen-server~ ]#cat/home/mysql/a.txt 

1,8 

2,b 
3,c 





在 Windows 平 台 下 ， 由 于 换行 符 是 Ann”， 因 此 在 导出 时 可 能 需要 指 
定 LINES TERMINATED BY 选项 ， 如 : 





[root@xen-servermysql]#mysql test-e"select*into outfile'/home/mysql/a.txt'fields terminated  by','lines terminated 
by'\r\n'from a"; 

[root@xen-servermysql]#od-c a.txt 

0000000 1,a\r\n 2,b\r\n 3,c\r\n 

0000017 





8.3.3 We UO BIKE 


mysqldump 的 恢复 操作 比较 简单， 因为 备份 的 文件 就 是 导出 的 SQL 
语句 ， 一 般 只 需要 执行 这 个 文件 就 可 以 了 ， 可 以 通过 以 下 的 方法 : 





[root@xen-server ~ ]#mysql-uroot-p<test_backup.sql 
r password: 





如 果 在 导出 时 包含 了 创建 和 删除 数据 库 的 SQL 语句 ， 那 必须 确保 删 
和 
以 下 的 错误 : 








mysql>drop database test; 
ERROR 1010(HY000):Error dropping database(can't rmdir'./test',errno:39) 





因为 逻辑 备份 的 文件 是 由 SQL 语句 组 成 的 ， 也 可 以 通过 SOURCE 命 
令 来 执行 导出 的 逻辑 备份 文件 ， 如 下 : 





mysql-source/home/mysql/test backup.sql; 
rows affected(0.00 sec) 
ows affected(0.00 s 


ooi oo 
oo oo 
RR RR 
oo oo 
zem cm 


uery OK, 
uery » ec) 
uery » ows affected(0.00 sec) 
uery " ows affected(0.00 sec) 





通过 mysqldump 可 以 恢复 数据 库 ， 但 是 经 党 发 生 的 一 个 问题 是 ， 
mysqldump 可 以 导出 存储 过 程 、 导 出 触发 器 、 导 出 事件 、 导 出 数据 ， 但 
是 却 不 能 导出 视图 。 因 此 ， 如 果 用 户 的 数据 库 中 还 使 用 了 视图 ， 那 么 在 
用 mysqldump 备 份 完 数据 库 后 还 需要 导出 视图 的 定义 ， 或 者 备份 视图 定 
、 并 在 恢复 时 进行 导入 ， 这 样 才能 保证 mysqldump 数 据 库 的 
完全 恢复 。 











8.3.4 LOAD DATA INFILE 


若 通 过 mysqldump-tab， 或 者 通过 SELECT INTO OUTFILE 导 出 的 数 
据 需 要 恢复 ， 这 时 可 以 通过 命令 LOAD DATA INFILE 来 进行 导入 。 
LOAD DATA INFILE 的 语法 如 下 : 








LOAD DATA INTO TABLE a IGNORE 1 LINES INFILE'/home/mysql/a.txt' 
REPLACE | IGNORE] 

INTO TABLE tbl name 

CHARACTER SET charset name] 

{FIELDS | COLUMNS} 

TERMINATED BY'string'] 

[OPTIONALLY]ENCLOSED BY'char'] 

ESCAPED BY'char'] 


LINES 
STARTING BY'string'] 
TERMINATED BY'string'] 


IGNORE number LINES] 
(col name or user var,...)] 
SET col namecexpr,...] 








要 对 服务 器 文件 使 用 LOAD DATA INEFILE， 必 须 拥 有 FILE 权 。 其 
中 对 于 导入 格式 的 选项 和 之 前 介绍 的 SELECT INTO OUTFILE 命 令 完全 
一 样 。IGNORE number LINES 选 项 可 以 忽略 导入 的 前 几 行 。 下 面 显示 一 
个 用 LOAD DATA INFILE 命 令 导入 文件 的 示例 ， 并 忽略 第 一 行 的 导 
入 : 








mysql>load data infile'/home/mysql/a.txt'into table a; 
Query OK,3 rows affected(0.00 sec) 
Records:3 Deleted:0 Skipped:0 Warnings:0 





为 了 加 快 mnoDB 存 储 引 擎 的 导入 ， 可 能 希望 导入 过 程 忽略 对 外 键 
的 检查 ， 因 此 可 以 使 用 如 下 方式 : 





mysql>SET@@foreign_key_checks=0; 

Query OK,0 rows affected(0.00 sec) 

mysql>LOAD DATA INFILE'/home/mysql/a.txt'INTO TABLE a; 
Query OK,4 rows affected(0.00 sec) 

Records:4 Deleted:0 Skipped:0 Warnings:0 
mysql>SET@@foreign_key_checks=1; 

Query OK,0 rows affected(0.00 sec) 





男 外 可 以 针对 指定 的 列 进行 导入 ， 如 将 数据 导入 列 a、b， 而 c 列 等 
于 a、 b 列 之 和 : 





mysql>CREATE TABLE b( 
->a INT, 
->b INT, 
->c INT, 


-— PRIMARY KEY(a) 

- >)ENGINE=InnoDB; 

Query OK,0 rows affected(0.01 sec) 
mysql>LOAD DATA INFILE'/home/mysql/a.txt' 
->INTO TABLE b FIELDS TERMINATED BY','(a,b) 
->SET c-atb; 

Query OK,4 rows affected(0.01 sec) 
Records:4 Deleted:0 Skipped:0 Warnings:0 
mysql>SELECT*FROM b; 


+---+------ Facesin * 
lalblcl 

站 二 * 
11/213] 

121315] 

141519] 

15161111 
+---+------ 4------ * 


4 rows in set(0.00 sec) 


p—M———————————— | 


8.3.5 mysqlimport 


mysqlimport 是 MySQL 数 据 库 提 供 的 一 个 命令 行程 序 ， 从 本 质 上 来 
说 ， 是 LOAD DATA EDT 命令 接口 ， 而 且 大 多 数 的 选项 都 和 LOAD 
DATA INFILE 语 法 相同 。 其 语法 格式 如 下 : 





shell>mysqlimport[options]db_name textfilei[textfile2...] 





和 LOAD DATA INFILE 不 同 的 是 ，mysqlimport 命 令 可 以 用 来 导入 
多 张 表 。 并 且 通 过 --user-thread 参 数 并 发 地 导入 不 同 的 文件 。 这 里 的 并 发 
是 指 并 发 导入 多 个 文件 ， 而 不 \ 是 指 mysqlimport 可 以 并 发 地 导入 一 个 文 
件 ， 这 和 古 有 明显 区 别 的 。 此 外 ， 通 第 来 次 并 及 地 对 同一 张 表 进 行 导入 ， 
般 都 不 会 比 串 行 的 方式 好 。 下 面 通过 mysqlimport 并 发 地 导入 2 
张 表 : 








[root@xen-servermysql]#mysqlimport--use-threads=2 test/home/mysql/t.txt/home/mysql/s.txt 
test.s:Records:5000000 Deleted:0 Skipped:0 Warnings:0 
test.t:Records:5000000 Deleted:0 Skipped:0 Warnings:0 





如 果 在 上 述 命令 的 运行 HOT 查看 MySQL 的 数据 库 线程 列表 ， 
应 该 可 以 看 到 类 似 如 下 内 容 





mysql- SHOW FULL Serene en 


User:re 

Host :www.dao.com:1028 

db: NULL 

Command:Binlog Dump 

Time: 37651 

State:Master has sent all binlog to slave;waiting for binlog to be updated 
Info:NULL 


Id:77 

User:root 

Host: localhost 

db:test 

Command: Query 
ime:0 


State: NULL 
Info:show full processlist 


User:root 

Host: localhost 

db:test 

Command: Query 

Time: 73 

State: NULL 

Info:LOAD DATA INFILE'/home/mysql/t.txt'INTO TABLE't'IGNORE © LINES 
ROGER ROGERII ORG OR RA py o o ooo o ooo 
Id:84 

User:root 

Host:localhost 

db:test 

Command : Query 

Time:73 

State :NULL 


Info:LOAD DATA INFILE'/home/mysql/s.txt'INTO TABLE'S'IGNORE 9 LINES 
4 rows in set(0.00 sec) 





可 以 看 到 mysqlimport 实 际 上 是 同时 执行 了 两 名 LOAD DTA INFILE 
并 发 地 导入 数据 。 


8.44 二 进 制 日 志 备份 与 恢复 


二 进 制 日 志 非 常 关键 ， 用 户 可 以 通过 它 完成 point-in-time 的 恢复 工 
作 。MySQL 数 据 库 的 replication 同 样 需要 二 进 制 日 志 。 在 默认 情况 下 并 
不 启用 二 进 制 日 志 ， 要 使 用 二 进 制 日 志 首 先 必须 启用 它 。 如 在 配置 文件 
中 进行 设置 : 








在 3.2.4 节 中 已 经 阐述 过 ， 对 于 InnoDB 存 储 引 擎 只 简单 启用 二 进 制 
志 是 不 够 的 ， 还 需要 启用 一 些 其 他 参数 来 保证 最 为 安全 和 正确 地 记录 
二 进 制 日 志 ， 因 此 对 于 InnoDB 存 储 引擎 ， 推 荐 的 二 进 制 日 志 的 服务 器 
配置 应 该 是 : 








在 备份 二 进 制 日 志文 件 前 ， 可 以 通过 FLUSH LOGS 命 令 来 生成 一 个 
新 的 二 进 制 日 志文 件 ， 然 后 备份 之 前 的 二 进 制 日 志 。 


要 恢复 二 进 制 日 志 也 是 非常 简单 的 ， 通 过 mysqlbinlog 即 可 。 
mysqlbinlog 的 使 用 方法 如 下 : 





shell>mysqlbinlog[options]log_fle... 





例如 要 还 原 binlog.0000001， 可 以 使 用 如 下 命令 : 





shell>mysqlbinlog binlog.0000001|mysql-uroot-p test 








GOR i KE S Hl EOC, BIE PAY ABI, 1 zee TA IN RAZ 
多 个 二 进 制 日 志文 件 ， 而 不 是 一 个 一 个 地 恢复 ， 如 : 





shell>mysqlbinlog binlog.[0-10]*|mysql-u root-p test 





也 可 以 和 匈 通 过 mysqlbinlog 命 令 导 出 到 一 个 文件 ， 然 后 再 通过 
Em oes 这 种 做 法 的 好 处 是 可 以 对 导出 的 文件 进行 修改 后 
y us H: 








shell>mysqlbinlog binlog.000001>/tmp/statements.sql 
shell>mysqlbinlog binlog.000002>>/tmp/statements.sql 
shell>mysql-u root-p-e"source/tmp/statements.sql" 





--Start-position 和 --stop-position 选 项 可 以 用 来 指定 从 二 进 制 日 志 的 某 
个 偏 移 量 来 进行 恢复 ， 这 样 可 以 跳 过 某 些 不 正确 的 语句 ， 如 : 





shell>mysqlbinlog--start-position=107856 binlog.0000001|mysql-uroot-p test 





--start-datetime 和 和 --stop-datetime 选 项 可 以 用 来 指定 从 二 进 制 日 志 的 
某 个 时 间 点 来 进行 恢复 ， 用 法 和 --start-position 和 --stop-position 选 项 基本 
相同 。 


8.5 Ae 


8.5.1 ibbackup 

ibbackup 是 mmnnoDB 存 储 引 擎 官方 提供 的 热 备 工具 ， 可 以 同时 备份 
MyISAM 存 储 引 擎 和 InnoDB 人 存储 引擎 表 。 对 于 InnoDB 存 储 引 擎 表 其 备 
份 工作 原理 如 下 : 


1) 记录 备份 开始 时 ，InnoDB 存 储 引 擎 重 做 日 志文 件 检查 点 的 
LSN. 


2) 复制 共 孚 表 空 间 文 件 以 及 独立 表 空 间 文件 。 


3) 记录 复制 完 表 空间 文件 后 ，InnoDB 存 储 引擎 重 做 日 志文 件 检查 
点 的 LSN。 


4) 复制 在 备份 时 产生 的 重 做 日 志 。 

对 于 事务 的 数据 库 ， 如 Microsoft SQL Server 数 据 库 和 Oracle 数 据 
库 ， 热 备 的 原理 大 致 和 上 述 相 同 。 可 以 发 现 ， 在 备份 期 间 不 会 对 数据 库 
本 身 有 任何 影响 ， 所 做 的 操作 只 是 复制 数据 库 文 件 ， 因 此 任何 对 数据 库 
的 操作 都 是 允许 的 ， 不 会 阻 窜 任 何 操作 。 故 ibbackup 的 优点 如 下 : 

口 在 线 备份 ， 不 阻塞 任何 的 SQL 语句 。 

口 备份 性 能 好 ， 备 份 的 实质 是 复制 数据 库 文件 和 重 做 日 志文 件 。 

口 文 持 压缩 备份 ， 通 过 选项 ， 可 以 文 持 不 同 级 别 的 压缩 。 


口 跨 平 台 支 持 ，ibbackup 可 以 运行 在 Linuvx、Windows 以 及 主流 的 
UNIX 系 统 平台 上 。 


ibbackup 对 InnoDB 存 储 引 擎 表 的 恢复 步骤 为 : 
口 恢 复 表 空 间 文 件 。 
口 应 用 重 做 日 志文 件 。 























ibbackup 提 供 了 一 种 高 性 能 的 热 备 方式 ， 是 InnoDB 存 储 引 擎 备份 的 
首先 方式。 不 过 它 是 收费 软件 ， 并 非 免 费 的 软件 。 好 在 开源 的 魅力 束 在 
于 社区 的 力量 ，Percona 公 司 给 用 户 带 来 了 开源 、 人 免费 的 XtraBackup 热 备 
工具 ， 所 实现 所 有 ibbackup 的 功能 ， 并 且 扩 展 文 持 了 真正 的 增 量 备份 功 
能 。 因 此 ， 更 好 的 选择 是 使 用 XtraBackup 来 完成 热 备 的 工作 。 








8.5.2 XtraBackup 


XtraBackup 备 份 工具 是 由 Percona 公 司 开 发 的 开源 热 备 工具 。 支 持 
MySQL5.0 以 上 的 版 本 。XtraBackup 在 GPL ”v2 开源 下 发 布 ， 官 网 地 址 


是 : https://launchpad.net/percona-xtrabackup。 


xtrabackup 命 令 的 使 用 方法 如 下 : 





xtrabackup- -backup| - -prepare[OPTIONS] 





xtrabackup 命 令 的 可 选 参数 如 下 : 





(The defaults options should be given as the first argument) 

--print-defaults Prints the program's argument list and exit. 

--no-defaults Don't read the default options from any file. 

--defaults-file=Read the default options from this file. 

--defaults-extra-file-Read this file after the global options files have been read. 

--target-dir-The destination directory for backups. 

--backup Make a backup of a mysql instance. 

--stats Calculate the statistic of the datadir(it is recommended you take mysqld offline). 

--prepare Prepare a backup so you can start mysql server with your restore. 

--export Create files to import to another database after it has been prepared. 

--print-param Print the parameters of mysqld that you will need for a forcopyback. 

--use-memory-This value is used instead of buffer pool size. 

--suspend-at-end Creates a file called xtrabackup suspended and waits until the user deletes that file at the end of the 
backup. 

--throttle-(use with--backup)Limits the IO operations(pairs of reads and writes)per second to the values set here. 

--log-stream outputs the contents of the xtrabackup logfile to stdout. 

--incremental-lsn-(use with--backup)Copy only.ibd pages newer than the specified LSN high: low.##ATTENTION##: checkpoint 
lsn*must*be used.Be Careful! 

--incremental-basedir-(use with--backup)Copy only.ibd pages newer than the existing backup at the specified directory. 

--incremental-dir-(use with--prepare)Apply.delta files and logfiles located in the specified directory. 

--tables-name Regular Expression list of table names to be backed up. 

--create-ib-logfile(NOT CURRENTLY IMPLEMENTED)will create ib logfile*after a--prepare. 

###If you want to create ib logfile*only re-execute this 

command using the same options.### 

--datadir-name Path to the database root. 

--tmpdir-name Path for temporary files.Several paths may be specified as a colon(:)separated string. 

If you specify multiple paths they are used round-robin. 





如 于 用 户 要 做 一 个 完全 备份 ， 可 以 执行 如 下 命令 : 





#./xtrabackup--backup 

./xtrabackup Ver alpha-0.2 for 5.0.75 unknown-linux-gnu(x86 64) 

>>log scanned up to(0 1009910580) 

Copying./ibdatai 

to/home/kinoyasu/xtrabackup work/mysql-5.0.75/innobase/xtrabackup/tmp2/ibdatai 

.. done 

Copying./tpcc/stock.ibd 

to/home/kinoyasu/xtrabackup work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/stock.ibd 
... done 

Copying./tpcc/new orders.ibd 

to/home/kinoyasu/xtrabackup work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/new orders.ibd 
.. done 

Copying./tpcc/history.ibd 

to/home/kinoyasu/xtrabackup work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/history.ibd 
...done 

Copying./tpcc/customer.ibd 
to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/customer .ibd 
>>log scanned up to(0 1010561109) 

...done 

Copying./tpcc/district.ibd 
to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/district.ibd 
...done 

Copying./tpcc/item.ibd 


to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/item. ibd 
...done 
Copying./tpcc/order_line. ibd 
to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/order_line.ibd 
>>log scanned up to(0 1012047066) 
...done 
Copying./tpcc/orders.ibd 
to/home/kinoyasu/xtrabackup work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/orders.ibd 
...done 
Copying. /tpcc/warehouse. ibd 
to/home/kinoyasu/xtrabackup_work/mysql-5.0.75/innobase/xtrabackup/tmp2/tpcc/warehouse. ibd 
...done 

710g scanned up to(0 1014592707) 

Stopping log copying thread.. 

Transaction log of 1sn(0 1009910580)to(0 1014592707)was copied. 











可 以 看 到 在 开始 备份 时 ，xtrabackup 首 先 记 录 了 重 做 日 志 的 位 置 ， 
在 上 述 示例 中 为 (0 1009910580) 。 然 后 对 备份 的 InnoDB 存 储 引 擎 表 的 
物理 文件 ， 即 共享 表 空 间 和 独立 表 空 间 进 行 copy 操 作 ， 这 里 可 以 看 到 输 
出 有 Copying...to...。 最 后 记录 备份 完成 后 的 重 做 日 志 位 置 CO 
1014592707) 。 


8.5.3 XtraBackup 实 现 增 量 备份 


MySQL 数 据 库 本 身 提 供 的 工具 并 不 支持 真正 的 增 量 备份 ， 更 准确 
地 说 ， 二 进 制 日 志 的 恢复 应 该 是 point-in-time 的 恢复 而 不 是 增 量 备份 。 
而 XtraBackup 工 具 文 持 对 于 InnoDB 存 储 引 擎 的 增 量 备份 ， 其 工作 原理 如 
下 : 





1) 首选 完成 一 个 全 备 ， 并 记录 下 此 时 检查 点 的 LSN。 


2) 在 进行 增 量 备份 时 ， 比 较 表 空间 中 每 个 页 的 LSN 是 否 大 于 上 次 
备份 时 的 LSN， 如 果 是 ， 则 备份 该 页 ， 同 时 记录 当前 检查 点 的 LSN。 


此 XtraBackup 的 备份 和 恢复 的 过 程 大 致 如 下 : 




















(full backup) 
&./xtrabackup- -backup- -target-dir-/backup/base 


(incremental backup 

#./xtrabackup- -backup- -target-dir-/backup/delta--incremental-basedir-/backup/base 
(prepare) 

4./xtrabackup- -prepare--target-dir-/backup/base 


(apply incremental backup) 
&./xtrabackup- -prepare--target-dir-/backup/base--incremental-dir-/backup/delta 





在 上 述 过 程 中 ， 首 先 将 全 部 文件 备份 到 /backup/base 目 录 下 ， 增 量 
备份 产生 的 文件 备份 到 /backup/delta。 在 恢复 过 程 中 ， 首 先 指 定 全 备 的 
路 径 ， 然 后 将 增 量 的 备份 应 用 于 该 完全 备份 。 以 下 显示 了 一 个 完整 的 增 
量 备份 过 程 : 








#./xtrabackup--backup 
./xtrabackup Ver beta-0.4 for 5.0.75 unknown-linux-gnu(x86 64) 
>>log scanned up to(0 378161500) 














The latest check point(for incremental):'0:377883685' —-----[EH]3X 4- LSN 
>>log scanned up to(0 379294296) 

Stopping log copying thread.. 

Transaction log of lsn(0 377883685)to(0 379294296)was copied. 

(must do--prepare before the each incremental backup) 

4./xtrabackup- -prepare 


#./xtrabackup- -backup- -incremental-0:377883685 

incremental backup from 0:377883685 is enabled. 

./xtrabackup Ver beta-0.4 for 5.0.75 unknown-linux-gnu(x86 64) 

>>log scanned up to(0 379708047) 

Copying./ibdatai 

to/home/kinoyasu/xtrabackup work/mysql-5.0.75/innobase/xtrabackup/tmp diff/ibdatai.delta 
...done 


The latest check point(for incremental) :'0:379438233'<==== F— 4H ht #1) JF T8 f] LSN 
>>log scanned up to(0 380663549) 

Stopping log copying thread.. 

Transaction log of lsn(0 379438233)to(0 380663549)was copied. 


pM——————— | 


8.6 ”快照 备份 


MySQL 数 据 库 本 身 并 不 文 持 快照 功能 ， 因 此 快照 备份 是 指 通过 文 
件 系统 文 持 的 快照 功能 对 数据 库 进 行 备份 。 备 份 的 前 提 是 将 所 有 数据 库 
文件 放 在 同一 文件 分 区 中 ， 然 后 对 该 分 区 进行 快照 操作 。 支 持 快 照 功 能 
的 文件 系统 和 设备 包括 FreeBSD 的 UFS 文 件 系 统 ，Solaris 的 ZFS 文 件 系 
统 ，GNU/Linux 的 逻辑 管理 器 (Logical Volume Manager, LVM) 等 。 
这 里 以 LVM 为 例 进 行 介 绍 ，UFS 和 ZEFS 的 快照 实现 大 致 和 LVM 相 似 。 


LVM 是 LINUX 系 统 下 对 磁盘 分 区 进行 管理 的 一 种 机 制 。LVM 在 硬 
盘 和 分 区 之 上 建立 一 个 逻辑 层 ， 来 提高 磁盘 分 区 管理 的 灵活 性 。 管 理 员 
可 以 通过 LVM 系 统 轻 松 管理 磁盘 分 区 ， 例 如 ， 将 知 干 个 磁盘 分 区 连接 
为 一 个 整 块 的 卷 组 (Volume Group) ， 形 成 一 个 存储 池 。 管 理 员 可 以 在 
卷 组 上 随意 创建 逻辑 卷 (Logical Volumes) ， 并 进一步 在 逻辑 卷 上 创建 
文件 系统 。 管 理 员 通过 LVM 可 以 方便 地 调整 卷 组 的 大 小 ， 并 且 可 以 对 
破 盘 存储 按照 组 的 方式 进行 命名 、 管 理 和 分 配 。 简 单 地 说 ， 用 户 可 以 通 
过 LVM 由 物理 块 设备 〈 如 硬盘 等 ) 创建 物理 卷 ， 由 一 个 或 多 个 物理 卷 
最 后 从 卷 组 中 创建 任意 个 逻辑 卷 〈 不 超过 卷 组 大 小 ) ， 如 图 
8-1PTZR © 
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图 8-1 LVM 工作 原理 





图 8-2 显 示 了 由 多 块 磁盘 组 成 的 逻辑 卷 LV0。 


physcal dsk 0 physteal dis | physical disk 2 
hdevhdd 








图 8-2 物理 到 逻辑 卷 的 映射 
通过 vgdisplay 命 令 查 看 系统 中 有 哪些 卷 组 ， 如 : 





[root@nh124-98~ ]#vgdisplay 
---Volume group--- 


< 
e 
z 
o 


Alloc PE/Size 66560/260.00 GB 
Free PE/Size 198/792.00 MB 
VG UUID MQJiye-j4NN-LbZG-F3CQ-UdTU- f o9D-RRfXD5 








vgdisplay 命 令 的 输出 结果 显示 当前 系统 有 一 个 rep 的 卷 组 ， 大 小 为 


260.77GB， 该 卷 组 访问 权限 是 read/write 等 。 命 令 lvdisplay 可 以 用 来 查看 
当前 系统 中 有 哪些 逻辑 卷 : 





[root@nh124-98~ ]#lvdisplay 


---Logical volume--- 

LV Name/dev/rep/repdata 

VG Name rep 

LV UUID 7tOlDt-seKZ-ChpY-QMXC-WaFD -ZXA1-MRbofK 
LV Write Access read/write 

LV snapshot status source of 

/dev/rep/dho datasnapshot100805143507 [active] 
/dev/rep/dho . datasnapshot100805163504 [active] 
LV Status available 

#open 1 

LV Size 100.00 GB 

Current LE 25600 

Segments 1 

Allocation inherit 

Read ahead sectors auto 

-currently set to 256 

Block device 253:0 

---Logical volume--- 

LV Name/dev/rep/dho_datasnapshot100805143507 
VG Name re 

LV UUID fSSXzh-IBnZ-aZIn-eP03-b7pk-CPjN-5xUktE 
LV Write Access read on 

LV snapshot status active destination for/dev/rep/repdata 
LV Status available 

#open 0 

LV Size 100.00 GB 

Current LE 25600 

COW-table size 80.00 GB 

COW-table LE 20480 

Allocated to snapshot 0.13% 

Snapshot chunk size 4.00 KB 

Segments 1 

Allocation inherit 

Read ahead sectors auto 

-currently set to 256 

Block device 253:1 

---Logical volume--- 

LV Name/dev/rep/dho datasnapshot100805163504 
VG Name re 

LV UUID 3B9NP1-qWwVG-pf JY -Bdgm-DIdD-dUMu-s2L6qJ 
LV Write Access read onl 

LV snapshot status active destination for/dev/rep/repdata 
LV Status available 

#open 0 

LV Size 100.00 GB 

Current LE 25600 

COW-table size 80.00 GB 

COW-table LE 20480 

Allocated to snapshot 0.0296 

Snapshot chunk size 4.00 KB 

Segments 1 

Allocation inherit 

Read ahead sectors auto 

-currently set to 256 

Block device 253:4 





可 以 看 到 ， 一 共有 3 个 逻辑 卷 ， 都 属于 卷 组 rep， 每 个 逻辑 卷 的 大 小 
都 是 100GB。/devreprepdata 这 个 逻辑 卷 有 两 个 只 读 快 照 ， 并 且 当 前 都 
是 激活 状态 的 。 


LVM 使 用 了 写 时 复制 CCopy-on-write) 技术 来 创建 快照 。 当 创建 一 
个 快照 时 ， 仅 复制 原始 卷 中 数据 的 元 数据 (neta data) ， 并 不 会 有 数据 
的 物理 操作 ， 因 此 快照 的 创建 过 程 是 非常 快 的 。 当 快照 创建 完成 ， 原 始 
卷 上 有 写 操 作 时 ， 快 照会 跟踪 原始 卷 块 的 改变 ， 将 要 改变 的 数据 在 改变 
之 前 复制 到 快照 预 留 的 空间 里 ， 因 此 这 个 原理 的 实现 叫做 写 时 复制 。 而 
对 于 快照 的 读 取 操作 ， 如 果 读 取 的 数据 块 是 创建 快照 后 没有 修改 过 的 ， 
那么 会 将 读 操 作 直 接 重 定 同 到 原始 卷 上 ， 如 果 要 读 取 的 是 已 经 修改 过 的 
块 ， 则 将 读 取保 存在 快照 中 该 块 在 原始 卷 上 改变 之 前 的 数据 。 因 此 ， 采 
用 写 时 复制 机 制 保证 了 读 取 快照 时 得 到 的 数据 与 快照 创建 时 一 致 。 














图 8-3 显 示 了 LVM 的 快照 读 取 ， 可 见 B 区 块 被 修改 了 ， 因 此 历史 数 
据 放 入 了 快照 区 域 。 读 取 快 照 数据 时 ，A、C、DD 块 还 是 从 原 有 卷 中 读 
取 ， 而 B 块 就 需要 从 快照 读 取 了 。 


数据 来 源 卷 快照 区 域 





快照 读 取 





图 8-3 LVM 快 照 读 取 


命令 lvcreate 可 以 用 来 创建 一 个 快照 ，--permission Tr 表 示 创 建 的 快照 


是 只 读 的 : 





[root@nh119-215 data]#lvcreate--size 100G--snapshot--permission r-n datasnapshot/dev/rep/repdata 
Logical volume"datasnapshot"created 





在 快照 制作 完成 后 可 以 用 lvdisplay 命 令 查看 ， 输 出 中 的 COW-table 
size 字 段 表 示 该 快照 最 大 的 空间 大 小 ，Allocated to snapshot 字 段 表 示 访 
快照 目前 空间 的 使 用 状况 : 





[root@nh124-98~ ]#lvdisplay 


---Logical volume--- 

LV Name/dev/rep/dho datasnapshot100805163504 
VG Name rep 

LV UUID 3B9NP1-qWwVG-pf JY -Bdgm-DIdD-dUMu-s2L6qJ 
LV Write Access read only 

LV snapshot status active destination for/dev/rep/repdata 
LV Status available 

#open 0 

LV Size 100.00 GB 

Current LE 25600 

COW-table size 80.00 GB 

COW-table LE 20480 

Allocated to snapshot 0.04% 

Snapshot chunk size 4.00 KB 

Segments 1 

Allocation inherit 

Read ahead sectors auto 

-currently set to 256 

Block device 253:4 





可 以 看 到 ， 当 前 快照 只 使 用 0.04% 的 空间 。 人 快照 在 最 初创 建 时 总 是 
很 小 ， 当 数据 来 源 卷 的 数据 不 断 被 修改 时 ， 这 些 数 据 库 才 会 放 入 快照 空 
间 ， 这 时 快照 的 大 小 才 会 慢 慢 增 大 。 


用 LVM 快 照 备份 InnoDB 存 储 引 擎 表 相当 简单 ， 只 要 把 与 IhnoDB 存 
储 引 擎 相关 的 文件 如 共享 表 空间 、 独 立 表 空间 、 重 做 日 志文 件 等 放 在 同 
一 个 逻辑 卷 中 ， 然 后 对 这 个 逻辑 卷 做 快照 备份 即 可 。 


在 对 InnoDB 存 储 引 擎 文件 做 快照 时 ， 数 据 库 无 顷 关 闭 ， 即 可 以 进 
行 在 线 备份 。 昌 然 此 时 数据 库 中 可 能 还 有 任务 需要 往 磁 盘 上 写 数 据 ， 但 
这 不 会 妨碍 备份 的 正确 性 。 因 为 InnoDB 存 储 引 擎 是 事务 安全 的 引擎 ， 
在 下 次 恢复 时 ， 数 据 库 会 自动 检查 表 空 间 中 页 的 状态 ， 并 决定 是 否 应 用 
重 做 日 志 ， 恢 复 就 好 像 数 据 库 被 意外 重 司 了 。 























8.7 复制 


8.7.31 复制 鸭 工作 原理 


复制 Creplication) 是 MySQL 数 据 库 提 供 的 一 种 高 可 用 高 性 能 的 解 
决 方案 ， 一 般 用 来 建立 大 型 的 应 用 。 总 体 来 说 ，replication 的 工作 原理 
分 为 以 下 3 个 步骤 : 


1) 主 服务 器 (master〉 把 数据 更 改 记录 到 二 进 制 日 志 Cbinlog? 
中 。 


2) 从 服务 器 〈slave) 把 主 服务 器 的 二 进 制 日 志 复 制 到 自己 的 中 继 
日 志 (relay log) +. 


3) 从 服务 器 重 做 中 继 日 志 中 的 日 志 ， 把 更 改 应 用 到 上 自己 的 数据 库 
上 ， 以 达到 数据 的 最 终 一 致 性 。 


复制 的 工作 原理 并 不 复杂 ， 其 实 残 是 一 个 完全 备份 加 上 二 进 制 日 志 
备份 的 还 原 。 不 同 的 是 这 个 二 进 制 日 志 的 还 原 操作 基本 上 实时 在 进行 
中 。 这 里 特别 需要 注意 的 是 ， 复 制 不 是 完全 实时 地 进行 同步 ， 而 是 异步 
实时 。 这 中 间 存 在 主 从 服务 器 之 间 的 执行 延 时 ， 如 果 主 服务 器 的 压力 很 
大 ， 则 可 能 导致 主 从 服务 器 延 时 较 大 。 复 制 的 工作 原理 如 图 8-4 所 示 。 






































Al 8-4 MySQL 数据 库 的 复制 工作 原理 


从 服务 器 有 2 个 线程 ， 一 个 是 IO 线程 ， 负 责 读 取 主 服务 露 的 二 进 制 
日 志 ， 并 将 其 保存 为 中 继 日 志 ; 男 一 个 是 SQL 线 程 ， 复 制 执行 中 继 日 
志 。MySQL4.0 版 本 之 前 ， 从 服务 器 只 有 1 个 线程 ， 既 负责 读 取 二 进 制 日 
志 ， 又 负责 执行 二 进 制 日 志 中 的 SQL 语句 。 这 种 方式 不 符合 高 性 能 的 要 
Du er 因此 如 果 碍 看 一 个 从 服务 器 的 状态 ， 应 该 可 以 看 到 类 
以 如 下 内 容 : 








mysql- SHOW FULL PROCESSLIST\G; 
FOI IO IO IRI IO a i ee 4. POW II IO II ICICI III Ik 


User:system user 
Host: 


db: NULL 

Command: Connect 

Time: 6501 

State:Waiting for master to send event 
Info:NULL 


Id:2 

User:system user 

Host: 

db: NULL 

Command: Connect 

Time :0 

State:Has read all relay log;waiting for the slave I/O thread to update it 
Info:NULL 


Id:206 

User:root 

Host: localhost 

db: NULL 

Command: Query 
ime:0 


State: NULL 
Info:SHOW FULL PROCESSLIST 
3 rows in set(0.00 sec) 





ALAA SIDA LI ZEE IEVOZ EE. FAI TARAS er RE E BLA in x 
送 二 进 制 日 志 。JID 为 2 的 线程 是 SQL 线程 ， 负 责 读 取 中 继 日 志 并 执行 。 
目前 的 状态 古 已 读 取 所 有 的 中 继 日 志 ， 等 待 中 继 日 志 被 1/O 线 程 更 新 。 


在 replication 的 主 服务 器 上 应 该 可 以 看 到 一 个 线程 负 贡 发 送 二 进 制 
日 志 ， 类 似 内 容 如 下 : 








mysql- SHOW FULL PROCESSLIST\G; 


Id:26541 

User:rep 

Host:192.168.190.98:39549 

db:NULL 

Command:Binlog Dump 

Time:6857 

State:Has sent all binlog to slave;waiting for binlog to be updated 
Info:NULL 








之 前 已 经 说 过 MySQL 的 复制 是 异步 实时 的 ， 并 非 完全 的 主 从 同 


步 。 若 用 户 要 想 得 知 当前 的 延迟 ， 可 以 通过 命令 SHOW SLAVE 
STATUS 和 SHOW MASTER STATUS 得 知 ， 如 : 





mysql SHOW SLAVE STATUSNG 
JOOOOOOOOOOOOOOOOOIOOGOOOOOOR] | pj FIG ICICI III III II I Ie 
Slave IO State:Waiting for master to send event 
Master Host:192.168.190.10 

Master User:rep 

Master Port:3306 

Connect Retry:60 

Master Log File:mysql-bin.000007 

Read Master Log Pos:555176471 

Relay Log File:gamedb-relay-bin.000048 
Relay Log Pos:224355889 

Relay Master Log File:mysql-bin.000007 
Slave IO Running:Yes 

Slave SQL Running:Yes 

Replicate Do DB: 

Replicate Ignore DB: 
Replicate Do Table: 

Replicate Ignore Table: 
Replicate Wild Do Table: 

Replicate Wild Ignore Table:mysql.?6,DBA.9?6 
Last Errno:O 

Last Error: 

Skip Counter:9 

Exec Master Log Pos:555176471 

Relay Log Space:224356045 

Until Condition:None 

Until Log File: 

Until Log Pos:0 

Master SSL Allowed:No 
Master SSL CA File: 
Master SSL CA Path: 

Master SSL Cert: 

Master SSL Cipher: 

Master SSL Key: 

Seconds Behind Master:0 

Master SSL Verify Server Cert:No 
Last IO Errno:0 

Last IO Error: 

Last SQL Errno:0 

Last SQL Error: 

1 row in set(0.00 sec) 





通过 SHOW SLAVE STATUS 命令 可 以 观察 当前 复制 的 运行 状态 ， 
一 些 主要 的 变量 如 表 8-1 所 示 。 


x E 
Slave 10 State 


Master Log File 


Read Master Log Pos |: 


Relay Master Log File 
Relay Log File 
Relay Log Pos 
Slave JO Running 
Slave SQL Running 


Exec Master Log Pos 





04 SHOW SLAVE STATUS 的 主要 变量 
说 " 

ibo IO ASH EB SERENA E 

Vat PR EU D ad EL mm BER EDU RY mysql 
tin 00007 

betta RAAB, HEFT HENRY 

i EE 8] mysqbi 00007 8 551741 f d, MEZEA T mysl 
bin. 000007 X 3E EL 529MB (5551764711024104) 的 内 容 

"i PSEUD EAN 
Vat ARTES 
Vo ARP GS NR 
人 服务 各 中 ]0 AENEAS, VES demi 
人 服务 各 中 SQL REMERAS, YES TUNER 


JONATA EMA EOE EGRE ENNE, (Read Master Log Pos - Exec 
Master Log Pos) AID ean Ni SQL AFEN, RUE. ENTER 
抽 主 从 服务 枯 是 完全 同步 的 


命令 SHOW MASTER STATUS 可 以 用 来 查看 主 服 务 器 中 二 进 制 日 


志 的 状态 ， 如 : 


mysql1- SHOW MASTER STATUS\G; 

ORO ROIG GIOI GIO] ppt eoo 
ile:mysql-bin.000007 

osition: 606181078 

inlog_Do_DB: 


n nore_DB: 
row in set(0.01 sec) 











"UE. fgg — HERA Sica I mw 166061810788) hz Eb. iZ4H 
减 去 这 一 时 间 点 时 从 服务 器 上 的 Read_Master Log _Pos， 就 可 以 得 知 IO 
线程 的 延 时 。 


对 于 一 个 优秀 的 MySQL 数 据 库 复 制 的 监控 ， 用 户 不 应 该 仅仅 监控 
从 服务 器 上 IO 线程 和 SQL 线程 运行 得 是 否 正 常 ， 同 时 也 应 该 监控 从 服 
务 串 和 主 服 务 器 之 间 的 延迟 ， 确 保 从 服务 器 上 的 数据 库 总 是 尽 可 能 地 接 
近 于 主 服务 左上 数据 库 的 状态 。 








8.7.2. ”快照 + 复制 的 备份 淋 构 
复制 可 以 用 来 作为 备份 ， 但 功能 不 仅 限于 备份 ， 其 主要 功能 如 下 : 


口 数 据 分 布 。 由 于 MySQL 数 据 库 提供 的 复制 并 不 需要 很 大 的 带宽 
要 求 ， 因 此 可 以 在 不 同 的 数据 中 心 之 间 实 现 数据 的 复制 。 


品读 取 的 负载 平衡 。 通 过 建立 多 个 从 服务 器 ， 可 将 读 取 平均 地 分 布 
到 这 些 从 服务 器 中 ， 并 有 日 减少 了 主 服务 器 的 压力 。 一 般 通 过 DNS 的 
Round-Robin 和 Linux 的 LVS 功 能 都 可 以 实现 负载 平衡 。 


口 数据 库 备 份 。 复 制 对 备份 很 有 帮助 ， 但 是 从 服务 器 不 是 备份 ， 不 
能 完全 代 答 备份 。 


口 高 可 用 性 和 故障 转移 。 通 过 复制 建立 的 从 服务 器 有 助 于 故障 转 
移 ， 减 少 故 障 的 停机 时 间 和 恢复 时 间 。 


可 见 ， 复 制 的 设计 不 是 简 简 单单 用 来 备份 的 ， 并 且 只 是 用 复制 来 进 
行 备份 是 远 远 不 够 的 。 假 设 当前 应 用 采用 了 主 从 的 复制 架构 ， 从 服务 器 
作为 备份 。 这 时 ， 一 个 初级 DBA 执 行 了 误 操 作 ， 如 DROP DATABASE 
或 DROP TABLE， 这 时 从 服务 器 也 跟着 运行 了 。 这 时 用 户 怎样 从 服务 器 
进行 恢复 呢 ? 


因此 ， 一 个 比较 好 的 方法 是 通过 对 从 服务 器 上 的 数据 库 所 在 分 区 做 
快照 ， 以 此 来 避免 误 操 作对 复制 造成 影响 。 当 发 生 主 服务 右上 的 误 操 作 
时 ， 只 需要 将 从 服务 器 上 的 快照 进行 恢复 ， 然 后 再 根据 二 进 制 日 志 进 行 
point-in-time 的 恢复 即 可 。 因 此 快照 + 复制 的 备份 架构 如 图 8-5 所 示 。 


























| 


| 的 备份 架构 


快照 + 复 秆 


图 8-5 


还 有 一 些 其 他 的 方法 来 调整 复制 ， 比 如 采用 延 时 复制 ， 即 间 欣 性 地 
开局 从 服务 器 上 的 同步 ， 保 证 大 约 一 小 时 的 延 时 。 这 的 确 也 是 一 个 方 
法 ， 只 是 数据 库 在 高 峰 和 非 高 峰 期 间 每 小 时 产生 的 二 进 制 日 志 量 是 不 同 
m RUE FEE NUM. 另外 ， 这 种 方法 也 不 能 完全 起 到 对 误 操 作 的 
仿 范 作用 。 


此 外 ， 建 议 在 从 服务 上 启用 read-only 选 项 ， 这 样 能 保证 从 服务 器 上 
的 数据 仅 与 主 服务 器 进行 同步 ， 避 免 其 他 线程 修改 数据 。 如 ; 





[m Eu 
read-on 





在 局 用 read-only 选 项 后 ， 如 果 操 作 从 服务 器 的 用 户 没有 SUPER 权 
限 ， 则 对 从 服务 器 进行 任何 的 修改 操作 会 抛 出 一 个 错误 ， 如 : 





mysql>INSERT INTO z SELECT 2; 
ERROR 1290(HY000):The MySQL server is running with the ead-only option so it cannot execute this statement 


8.8 ”小 结 


本 章 中 介绍 了 不 同 的 备份 类 型 ， 并 介绍 了 MySQL 数 据 库 沼 用 的 一 
些 备 份 方式 。 同 时 主要 介绍 了 对 于 InnoDB 存 储 引擎 表 的 备份 。 不 管 是 
mysqldump 还 是 xtrabackup 工 具 ， 都 可 以 对 InnoDB 存 储 引 擎 表 进 行 很 好 
的 在 线 热 备 工作 。 最 后 ， 介 绍 了 复制 ， 通 过 快照 和 复制 技术 的 结合 ， 
以 保证 用 户 得 到 一 个 异步 实时 的 在 线 MySQL 备 份 解决 方案 。 











Om ”性 能 调 优 


性 能 优化 不 是 一 项 简单 的 工作 ， 但 也 不 是 复杂 的 难事 ， 关 键 在 于 对 
InnoDB 存 储 引擎 特性 的 了 解 。 如 果 之 前 各 章 的 内 容 读者 已 经 完全 理解 
并 掌握 了 ， 那 就 应 该 基本 掌握 了 如 何 使 mnoDB 存 储 引擎 更 好 地 工作 。 
本 章 将 从 以 下 几 个 方面 集中 讲解 InnoDB 存 储 引擎 的 性 能 问题 ; 





口 选 择 合适 的 CPU 
口内 存 的 重要 性 

口 硬盘 对 数据 库 性 能 的 影响 
口 合理 地 设置 RAID 


口 操作 系统 的 选择 也 很 重要 
口 不 同文 件 系统 对 数据 库 的 影响 
口 选 择 合适 的 基准 测试 工具 


9.1 选择 合适 的 CPU 


用 户 首先 需要 清楚 当前 数据 库 的 应 用 类 型 。 一 般 而 言 ， 可 分 为 两 大 
类 : OLTP (Online Transaction Processing， 在 线 事务 处 理 ) 和 
OLAP (Online Analytical Processing， 在 线 分 析 处 理 ) 。 这 是 两 种 截然 
不 同 的 数据 库 应 用 。OLAP 多 用 在 数据 仓库 或 数据 集 市 中 ， 一 般 需 要 执 
行 复杂 的 SQL 语 句 来 进行 查询 ;OLTP 多 用 在 日 常 的 事物 处 理应 用 中 ， 
如 银行 交易 、 在 线 商品 交易 、Blog、 网 络 游戏 等 应 用 。 相 对 于 OLAP， 
数据 库 的 容量 较 小 。 


m InnoDB 存 储 引 擎 一 般 都 应 用 于 OLTP 的 数据 库 应 用 ， 这 种 应 用 的 特 
Wh: 





口 用 户 操作 的 并 发 量 大 

口 事务 处 理 的 时 间 一 般 比 较 短 

口 查 询 的 语句 较为 简单 ， 一 般 都 走 索 引 
OQ E RI Egi 


可 以 看 出 ，OLTP 的 数据 库 应 用 本 身 对 CPU 的 要 求 并 不 是 很 高 ， 
为 复杂 的 查询 可 能 需要 执行 比较 、 排 序 、 连 接 等 非常 耗 CPU 的 操作 ， 这 
些 操作 在 OLTP 的 数据 库 应 用 中 较 少 发 生 。 因 此 ， 可 以 说 OLAP 是 CPU 密 
集 型 的 操作 ， 而 OLTP 是 IO 密集 型 的 操作 。 建 议 在 采购 设备 时 ， 将 更 多 
的 注意 力 放 在 提高 IO 的 配置 上 。 


此 外 ， 为 了 获得 更 多 内 存 的 支持 ， 用 户 采购 的 CPU 必 须 支 持 64 位 ， 
否则 无 法 支持 64 位 操作 系统 的 安装 。 因 此 ， 为 新 的 应 用 选择 64 位 的 CPU 
是 必要 的 前 提 。 现 在 4 核 的 CPU 已 经 非常 普遍 ， 如 今 Intel 和 AMD 又 相继 
推出 了 8 核 的 CPU， 将 来 随 着 操作 系统 的 升级 我 们 还 可 能 看 到 128 核 的 
CPU， 这 都 需要 数据 库 更 好 地 对 其 提供 文 持 。 


从 InnoDB 存 储 引擎 的 设计 架构 上 来 看 ， 其 主要 的 后 台 操 作 都 是 在 
一 个 单独 的 master thread 中 完成 的 ， 因 此 并 不 能 很 好 地 支持 多 核 的 应 
用 。 当 然 ， 开 源 社区 已 经 通过 多 种 方法 来 改变 这 种 局 面 ， 而 InnoDB1.0 
版 本 在 各 种 测试 下 已 经 显示 出 对 多 核 CPU 的 处 理性 能 的 支持 有 了 极 大 的 














提高 ， 而 InnoDB 1.2 版 本 又 支持 多 个 purge 线 程 ， 以 及 将 刷新 操作 从 
master thread 中 分 离 出 来 。 因 此 ， 知 用 户 的 CPU 文 持 多 核 ，InnoDB 的 版 
本 应 该 选择 1.1 或 更 高 版 本 。 另 外 ， 如 果 CPU 是 多 核 的 ， 可 以 通过 修改 参 
数 innodb_read io_threads 和 innodb_write io_threads 来 增 大 IO 的 线程 ， 这 
样 也 能 更 充分 有 效 地 利用 CPU 的 多 核 性 能 。 


在 当前 的 MySQL 数 据 库 版 本 中 ， 一 条 SQL 查询 语句 只 能 在 一 个 CPU 
中 工作 ， 并 不 支持 多 CPU 的 处 理 。OLTP 的 数据 库 应 用 操作 一 般 都 很 简 
单 ， 因 此 对 OLTP 应 用 的 影响 并 不 是 很 大 。 但 是 ， 多 个 CPU 或 多 核 CPU 
对 处 理 大 并 发 量 的 请 求 还 是 会 有 帮助 。 














9.2 内存 的 重要 性 


内 存 的 大 小 是 最 能 直接 反映 数据 库 的 性 能 。 通 过 之 前 各 个 章节 的 介 
绍 ， 已 经 了 解 到 ImnoDB 存 储 引 擎 既 绥 存 数 据 ， 又 缓存 索引 ， 并 且 将 它 
们 缓存 于 一 个 很 大 的 缓冲 池 中 ， 即 InnoDB Buffer Pool。 因 此 ， 内 存 的 大 
小 直接 影响 了 数据 库 的 性 能 。Percona 公 司 的 CTO Vadim 对 此 做 了 一 次 测 
试 ， 以 此 反映 内 存 的 重要 性 ， 结 果 如 图 9-1 所 示 。 








sysbench oltp,80mln rows (18GB data) 
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图 9-1 不 同 内存 容 量 下 InnoDB 存 储 引 警 的 性 能 表现 


在 上 述 测 试 中 ， 数 据 和 索引 总 大 小 为 18GB， 然 后 将 缓冲 池 的 大 小 
分 别 设 为 2GB、4GB、6GB、8GB、10GB、12GB、14GB、16GB、 
18GB、20GB、22GB， 再 进行 sysbench 的 测试 。 可 以 发 现 ， 随 着 缓冲 池 
的 增 大 ， 测 试 结果 TPS (Transaction Per Second) 会 线性 增长 。 当 缓冲 
池 增 大 到 20GB 和 22GB 时 ， 数 据 库 的 性 能 有 了 极 大 的 提高 ， 因 为 这 时 组 
冲 池 的 大 小 已 经 大 于 数据 文件 本 身 的 大 小 ， 所 有 对 数据 文件 的 操作 都 可 
以 在 内 存 中 进行 。 因 此 这 时 的 性 能 应 该 是 最 优 的 ， 再 调 大 缓冲 池 并 不 能 
再 提高 数据 库 的 性 能 。 


所 以 ， 应 该 在 开发 应 用 前 预 估 “ 活 跃 ” 数 据 库 的 大 小 是 多 少 ， 并 以 此 
eee 当然 ， 要 使 用 更 多 的 内 存 还 必须 使 用 64 
立 的 操作 系统 。 


如 何 判断 当前 数据 库 的 内 存 是 否 已 经 达到 瓶颈 了 呢 ? 可 以 通过 查看 
当前 服务 器 的 状态 ， 比 较 物 理 磁 盘 的 读 取 和 内 存 读 取 的 比例 来 判断 缓冲 
oo iH 3$ InnoDB 4E fit 5| BEAN Se vtl RO) ia rp S NEU] F99%, 

H: 














mysql>SHOW GLOBAL STAUTS LIKE'innodb%read%'\G; 


OK IK KK I IK TOK IK IK KR IK KI pg RR RR k k e k RR ek ko k ek ke ee 


Value:0 

FOI TO IO IOI IOI TO TO IO Ik 2. TOW III I III IOI I IOk 
Variable name:Innodb buffer pool read ahead evicted 

Value:0 

FOI TOTTI TRI 3 FOI IO IO IO IOI TO TO IORI 1 


. TOW 
Variable name:Innodb buffer pool read requests 
Value:167051313 


.row 
Variable name:Innodb buffer pool reads 
Value:129236 


. TOW 
Variable name:Innodb data pending reads 
Value:0 

FOI III IO IOI Ik 6.ro 
Variable name:Innodb data read 
Value:2135642112 

AO III III IO IO Ik 7.ro 
Variable name:Innodb data reads 
Value:130309 

FOI TOIT TO IOI TOR TO IO I BOWE CIO III I II Ik 
Variable name:Innodb pages read 

Value:130215 


FORK RIOR hok koe koe ke ek koe ke ek ke ke ee 


HORROR OR RRR ek e e de e ke ek ek ek eee 


9. 
Variable name:Innodb rows read 
Value:17651085 
9 rows in set(0.00 sec) 





上 述 参 数 的 具体 含义 如 表 9-1 所 示 。 


$ 4 a 
lnod bute po reads FOEDE t V 
lnod frm rad ahead — |J — 


Ni E 


Inmodo buffer pool read ahead evicted 


lnod buf pool rad reus — | ARDEN 


Inodo data read Lite ect 
Todo data reds bant lA 


A PARI PATE SE PT E DU TRE : 


ine 


lnnod buffer pool read request 
db uf pool ed equeststHnnodb bur pool read abeadtlonodb buffer pool reads) 


从 上 面 的 例子 看 ， 绥 冲 池 命中 率 =167 051 313/ (167 051 3134129 
236+0) =99.92%. 


即使 缓冲 池 的 大 小 已 经 大 于 数据 库 文件 的 大 小 ， 这 也 并 不 意味 着 没 
有 磁盘 操作 。 数 据 库 的 缓冲 池 只 是 一 个 用 来 存放 热点 的 区 域 ， 后 台 的 线 
程 还 负责 将 脏 页 噶 步 地 写 入 到 磁盘 。 此 外 ， 每 次 事务 提交 时 还 需要 将 日 
志 写 入 重 做 日 志文 件 。 





9.3 ”硬盘 对 数据 库 性 能 的 影响 
9.3.1 ”传统 机 械 硬盘 


当前 大 多 数 数据 库 使 用 的 都 是 传统 的 机 械 硬盘 。 机 械 人 硬盘 的 技术 目 
前 已 非常 成 熟 ， 在 服务 器 领域 一 般 使 用 SAS 或 SATA 接 口 的 人 硬盘。 服务 
器 机 械 人 硬盘 开 始 癌 小 型 化 转型 ， 目 前 大 部 分 使 用 2.5 寸 的 SAS 机 械 便 往 。 


机 械 硬 盘 有 两 个 重要 的 指标 : 一 个 是 寻 道 时 间 ， 另 一 个 是 转速 。 当 
前 服务 器 机 械 人 硬盘 的 寻 道 时 间 已 经 能 够 达到 3ms， 转 速 为 15 
000RPM (rotate per minute) 。 传 统 机 械 人 硬盘 最 大 的 问题 在 于 读 写 做 
涉 ， 读 写 人 磁头 的 设计 使 硬盘 可 以 不 再 像 磁 带 一 样 ， 只 能 进行 顺序 访问 ， 
而 是 可 以 随机 访问 。 但 是 ， 机 械 硬 盘 的 访问 需要 耗费 长 时 间 的 磁头 旋转 
和 定位 来 查找， 因此 顺序 访问 的 速度 要 远 高 于 随机 访问 。 传 统 关 系数 据 
库 的 很 多 设计 也 都 是 在 尽量 充分 地 利用 顺序 访问 的 特性 。 


通常 来 说 ， 可 以 将 多 块 机 械 硬 盘 组 成 RAID 来 提高 数据 库 的 性 能 ， 
也 可 以 将 数据 文件 分 布 在 不 同 硬盘 上 来 达到 访问 负载 的 均衡 。 











9.3.2 ”固态 硬盘 


固态 硬盘 ， 更 准确 地 说 是 基于 闪存 的 固态 硬盘 ， 是 近 几 年 出 现 的 一 
种 新 的 存储 设备 ， 其 内 部 由 闪存 (Flash Memory) 组 成 。 因 为 闪存 的 低 
延迟 性 、 低 功 耗 ， 以 及 防震 性 ， 闪 存 设备 已 在 移动 设备 上 得 到 了 广泛 的 
应 用 。 企 业 级 应 用 一 般 使 用 固态 人 硬盘， 通过 并 联 多 块 内 存 来 进一步 提高 
数据 传输 的 吞吐 量 。 传 统 的 存储 服务 提供 商 EMC 公 司 已 经 开始 提供 基于 
闪存 的 固态 硬盘 的 TB 级 别 存储 解雇 方案。 数据库 厂商 Oracle 公 司 最 近 也 
开始 提供 绑 定 固态 硬盘 的 Exadata 服 务 器 。 


不 同 于 传统 的 机 械 人 硬盘 ， 闪 存 是 一 个 完全 的 电子 设备 ， 没 有 传统 机 
械 硬 盘 的 读 写 磁头 。 因 此 ， 固 态 便 盘 不 需要 像 传统 机 械 硬 盘 一 样 ， 需 要 
耗 帝 大 量 时 间 的 磁头 旋转 和 定位 来 得 找 数 据 ， 所 以 固态 硬盘 可 以 提供 一 
研究 的 。 


另 一 方面 ， 闪 存 中 的 数据 是 不 可 以 更 新 的 ， 只 能 通过 局 区 
(sector) 的 履 盖 重 写 ， 而 在 覆盖 重 写 之 前 ， 需 要 执行 非常 耗 时 的 探 除 
Cerase) 操作 。 探 除 操作 不 能 在 所 含 数 据 的 忆 区 上 完成 ， 而 需要 在 删除 
整个 被 称 为 探 除 块 的 基础 上 完成 ， 这 个 擦 除 块 的 尺寸 大 于 局 区 的 大 小 ， 
通常 为 128KB 或 者 256KB。 此 外 ， 每 个 探 除 块 有 擦 写 次 数 的 限制 。 己 经 
有 一 些 算法 来 解决 这 个 问题 。 但 是 对 于 数据 库 应 用 ， 需 要 认真 考虑 固态 
人 硬盘 在 写 入 方面 存在 的 问题 。 


因为 存在 上 述 写 入 方面 的 问题 ， 闪 存 提供 的 读 写 速度 是 非 对 称 的 。 
读 取 速度 要 远 快 于 写 入 的 速度 ， 因 此 对 于 固态 硬盘 在 数据 库 中 的 应 用 ， 
应 该 好 好 利用 其 读 取 的 性 能 ， 避 免 过 多 的 写 入 操作 。 


图 9-2 显 示 了 一 个 双 通 道 的 固态 硬盘 架构 ， 通 过 支持 4 路 的 闪存 交叉 
存储 来 降低 固态 硬盘 的 访问 延 时 ， 同 时 增 大 并 发 的 读 写 操作 。 通 过 进 一 
步 增加 通道 的 数量 ， 固 态 硬盘 的 性 能 可 以 线性 地 提高 ， 例 如 我 们 党 见 的 
Intel X-25M 回 态 便 盘 就 是 10 通 道 的 固态 便 松 。 
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图 9-2 双 通 道 的 固态 硬盘 架构 
由 于 内 存 是 一 个 完全 的 电子 设备 ， 没 有 读 写 磁头 等 移动 部 件 ， 因 此 





固态 硬盘 有 痢 较 低 的 访问 延 时 。 当 主机 发 布 一 个 读 写 请 求 时 ， 固 态 便 盘 
的 控制 器 会 把 VO 命 令 从 逻辑 地 址 映射 成 实际 的 物理 地 址 ， 写 操作 还 需 
要 修改 相应 的 映射 表 信息 。 算 上 这 些 额 外 的 开销 ， 固 态 便 盘 的 访问 延 时 
一 般 小 于 0.1ms 左 右 。 图 9-3 显 示 了 传统 机 械 硬 盘 、 内 存 、 固 态 便 盘 的 随 
机 访问 延 时 之 间 的 比较 。 








Random Access Time (ms) 


Memory | 01 


2.5 SAS Disk T 





图 9-3 固态 硬盘 和 传统 机 械 人 硬盘 随机 访问 延 时 的 比较 


对 于 固态 硬盘 在 InnoDB 存 储 引 擎 中 的 优化 ， 可 以 增加 
innodb_io_capacity 变 量 的 值 达到 充分 利用 固态 便 盘 带 来 的 高 IOPS 特 性 。 
不 过 这 需要 用 户 根据 自己 的 应 用 进行 有 针对 性 的 调整 。 在 InnoSQL 及 
InnoDB1.2 版 本 中 ， 可 以 选择 关闭 邻接 页 的 刷新 ， 同 样 可 以 为 数据 库 的 
性 能 融 来 一 定 效 果 的 提升 。 





此 外 ， 还 可 以 使 用 InnoSQL 开 发 的 L2 _ Cache 解决 方案 ， 该 解决 方案 
可 以 充分 利用 固态 硬盘 的 超 高 速 随机 读 取 性 能 ， 在 内 存 缓冲 池 和 传统 存 
储 层 之 间 建 立 一 层 基于 闪存 固态 人 硬盘 的 二 级 缓冲 池 ， 以 此 来 扩充 缓冲 池 
的 容量 ， 提 高 数据 库 的 性 能 。 与 基于 磁盘 的 固态 人 硬盘 Cache 类 似 的 解决 
方案 还 有 Facebook Flash Cache 和 bcache， 只 不 过 它们 是 基于 通用 文件 系 
统 的 ， 对 InnoDB 存 储 引 擎 本 身 的 优化 较 少 。 








94 合理 地 设置 RAID 
941 RAID 


RAID (Redundant Array of Independent Disks， 独 立 磁 盘 风 余数 组 ) 
的 基本 思想 就 是 把 多 个 相对 便宜 的 硬盘 组 合 起 来 ， 成 为 一 个 磁盘 数组 ， 
使 性 能 达到 甚至 超过 一 个 价格 昂贵 、 容 量 巨大 的 硬盘 。 由 于 将 多 个 便 盘 
组 合成 为 一 个 逻辑 局 区 ，RAID 看 起 来 就 像 一 个 单独 的 硬盘 或 逻辑 存储 
单元 ， 因 此 操作 系统 只 会 把 它 当 作 一 个 硬盘 。 


RAID 的 作用 是 : 

口 增强 数据 集成 度 
口 增强 容错 功能 

口 增加 处 理 量 或 容量 


根据 不 同 磁盘 的 组 合 方式 ， 常 见 的 RAID 组 合 方式 可 分 为 RAID 0、 
RAID 1. RAID 5、RAID 10 和 RAID 50 等 。 


RAID 0: 将 多 个 磁盘 合并 成 一 个 大 的 磁盘 ， 不 会 有 见 余 ， 并 行 
WO， 速 度 最 快 。RAID 0 亦 称 为 带 区 集 ， 它 将 多 个 磁盘 并 列 起 来 ， 使 之 
成 为 一 个 大 磁盘 ， 如 图 9-4 所 示 。 在 存放 数据 时 ， 其 将 数据 按 磁 盘 的 个 
数 进行 分 段 ， 同 时 将 这 些 数 据 写 进 这 些 盘 中 。 所 以 ， 在 所 有 的 级 别 中 ， 
RAID 0 的 速度 是 最 快 的。 但 是 RAID ”0 没有 宛 余 功 能 ， 如 果 一 个 磁盘 
(物理 ) 损坏 ， 则 所 有 的 数据 都 会 丢失 。 理 论 上 ， 多 磁盘 的 效能 就 等 于 
(单一 磁盘 效能 ) x〈 磁 盘 数 ) ， 但 实际 上 受 限 于 总 线 IO 瓶 颈 及 其 他 因 
素 的 影响 ，RAID 效 能 会 随 边际 递减 。 也 就 是 说 ， 假 设 一 个 磁盘 的 效能 
是 50MB/s， 两 个 磁盘 的 RAID 0 效能 约 96MB/s， 三 个 磁盘 的 RAID 0 也 许 
是 130MB/s 而 不 是 150MB/s。 
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图 9-4 RAID 0 结构 


RAID 1: 两 组 以 上 的 N 个 磁盘 相互 作为 镜像 〈 如 图 9-5 所 示 ) ， 在 
一 些 多 线程 操作 系统 中 能 有 很 好 的 读 取 速 度 ， 但 写 入 速度 略 有 降低 。 除 
非 拥 有 相同 数据 的 主 磁盘 与 镜像 同时 损坏 ， 和 否则 只 要 一 个 磁盘 正常 即 可 
维持 运作 ， 可 靠 性 最 高 。RAID 1 就 是 镜像 ， 其 原理 为 在 主 硬盘 上 存放 数 
据 的 同时 也 在 镜像 硬盘 上 写 相 同 的 数据 。 当 主 硬盘 (物理 ) 损坏 时 ， 镜 
像 硬 盘 则 代替 主人 硬盘 的 工作 。 因 为 有 镜像 便 盘 做 数据 备份 ， 所 以 RAID 1 
的 数据 安全 性 在 所 有 的 RAID 级 别 上 来 说 是 最 好 的 。 但 是 ， 无 论 用 多 少 
oda. 1， 仪 算 一 个 磁盘 的 容量 ， 是 所 有 RAID 中 磁盘 利用 率 最 
氏 的 一 个 级 别 。 
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图 9-5 RAID 1 结构 


RAID 5: 是 一 种 存储 性 能 、 数 据 安全 和 存储 成 本 兼顾 的 存储 解决 方 
案 。 它 使 用 的 是 Disk Striping (人 硬盘 分 区 ) 技术 。RAID 5 至 少 需要 三 个 
ERE, RAID 5 不 对 存储 的 数据 进行 备份 ， 而 是 把 数据 和 相对 应 的 奇偶 校 
验 信息 存储 到 组 成 RAID 5 的 各 个 磁盘 上 ， 并 且 奇 偶 校 验 信息 和 相对 应 的 
数据 分 别 存储 于 不 同 的 磁盘 上 。 当 RAID 5 的 一 个 磁盘 数据 发 生 损坏 后 ， 
利用 剩 下 的 数据 和 相应 的 奇偶 校 验 信 息 去 恢复 被 损坏 的 数据 。RAID 5 可 
以 理解 为 是 RAID 0 和 RAID 1 的 折 中 方案 。RAID 5 可 以 为 系统 提供 数据 
安全 保障 ， 但 保障 程度 要 比 镜 像 低 而 磁盘 空间 利用 率 要 比 镜像 高 。 
RAID 5 具有 和 RAID 0 相近 似 的 数据 读 取 速度 ， 只 是 多 了 一 个 奇 侦 校 验 
信息 ， 写 入 数据 的 速度 相当 慢 ， 若 使 用 Write ”Back 可 以 让 性 能 改善 不 
少 。 同 时 ， 由 于 多 个 数据 对 应 一 个 奇偶 校 验 信 息 ，RAID 5 的 磁盘 空间 利 
用 率 要 比 RAID 1 高 ， 存 储 成 本 相对 较 低 。RAID 5 的 结构 如 图 9-6 所 示 。 
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图 9-6 RAID 5 结构 





RAID 10 和 RAID 01: RAID 10 是 先 镜像 再 分 区 数据 ， 将 所 有 硬盘 分 
为 两 组 ， 视 为 RAID ”0 的 最 低 组 合 ， 然 后 将 这 两 组 各 自视 为 RAID 1 运 
作 。RAID 10 有 着 不 错 的 读 取 速度 ， 而 且 拥 有 比 RAID 0 更 高 的 数据 保护 
TE. RAID 01 则 与 RAID 10 的 程序 相反 ， 先 分 区 再 将 数据 镜 射 到 两 组 便 
盘 。RAID 01 将 所 有 的 硬盘 分 为 两 组 ， 变 成 RAID 1 的 最 低 组 合 ， 而 将 两 
组 人 硬盘 各 自视 为 RAID 0 运作 。RAID 01 比 RAID 10 有 着 更 快 的 读 写 速 
度 ， 不 过 也 多 了 一 些 会 让 整个 硬盘 组 停止 运转 的 几率 ， 因 为 只 要 同一 组 
的 硬盘 全 部 损毁 ，RAID 01 就 会 停止 运作 ， 而 RAID 10 可 以 在 牺牲 RAID 
0 的 优势 下 正常 运作 。RAID 10 巧 妙 地 利用 了 RAID 0 的 速度 及 RAID 1 的 
安全 〔( 保 护 ) 两 种 特性 ， 它 的 缺点 是 需要 较 多 的 人 硬盘， 因为 至 少 必须 拥 
有 四 个 以 上 的 偶数 硬盘 才能 使 用 。RAID 10 和 RAID 01 的 结构 如 图 9-7 所 





MID Il RAID 0) 
RAID} MID | 


MID | MID | RAIDO RAIDO 


图 9-7 RAID 10 和 RAID 01 结 构 


RAID 50: RAID 50 也 被 称 为 镜像 阵列 条 带 ， 由 至 少 六 块 硬 盘 组 
成 ， 像 RAID “0 一 样 ， 数 据 被 分 区 成 条 带 ， 在 同一 时 间 内 癌 多 块 磁 盘 写 
A; BRAID 5 一 样 ， 也 是 以 数据 的 校 验 位 来 保证 数据 的 安全 ， 且 校 验 条 





市 均匀 分 布 在 各 个 磁盘 上 ， 其 目的 在 于 提高 RAID 5 的 读 写 性 能 。 
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9-8 RAID 50 结 构 


对 于 数据 库 应 用 来 说 ，RAID 10 是 最 好 的 选择 ， 它 同时 兼顾 了 RAID 


DS 


1 和 RAID 0 的 特性 。 但 是 ， 当 一 个 磁盘 失效 时 ， 性 能 可 能 会 受到 很 大 的 
影响 ， 因 为 条 带 (strip) 会 成 为 瓶颈 。 我 曾 在 生产 环境 下 遇 到 过 的 情况 
是 ， 两 台 负 载 基本 相同 的 数据 库 ， 一 台 正 常 的 服务 器 磁盘 IO 负载 为 20% 
左右 ， 而 男 一 台 服 务 嚣 IO 负载 却 高 达 90%。 








9.4.2 RAID Write Back 功 能 


RAID Write Back 功 能 是 指 RAID 控 制 器 能 够 将 写 入 的 数据 放 入 自身 
的 缓存 中 ， 并 把 它们 安排 到 后 面 再 执行 。 这 样 做 的 好 处 是 ， 不 用 等 待 物 
理 磁 盘 实 际 写 入 的 完成 ， 因 此 写 入 变 得 更 快 了 。 对 于 数据 库 来 说 ， 这 显 
得 十 分 重要 。 例 如 ， 对 重 做 日 志 的 写 入 ， 在 将 sync_binlog 设 为 1 的 情况 
下 二 进 制 日 志 的 写 入 、 脏 页 的 刷新 等 都 可 以 使 性 能 得 到 明显 的 提升 。 


但 是 ， 当 操作 系统 或 数据 库 关 机 时 ，Write _ Back 功能 可 能 会 破坏 数 
据 库 的 数据 。 这 是 由 于 已 经 写 入 的 数据 库 可 能 还 在 RAID 卡 的 缓存 中 ， 
数据 可 能 并 没有 完全 写 入 磁盘 ， 而 这 时 故障 发 生 了 。 为 了 解决 这 个 问 
题 ， 目 前 大 部 分 的 硬件 RAID 卡 都 提供 了 电池 备份 单元 (BBU, Battery 
Backup Unit) ， 因 此 可 以 放心 地 开启 Write Back 的 功能 。 不 过 我 发 现 每 
台 服 务 器 的 出 厂 设置 都 不 相同 ， 应 该 将 RAID 设 置 要 求 告 知 服务 器 提供 
商 ， 开 启 一 些 认为 需要 的 参数 。 


如 果 没 有 局 用 Write ”Back 功能， 那么 在 RAID 卡 设置 中 显示 的 就 是 
Write Through. Write Through 没 有 绥 冲 写 入 ， 因 此 写 入 性 能 可 能 不 是 很 
好 ， 但 它 却 是 最 安全 的 写 入 。 


即使 用 户 开 局 了 Write Back 功 能 ，RAID 卡 也 可 能 只 是 在 Write 
Through 模 式 下 工作 。 这 是 因为 安全 使 用 Write Back 的 前 提 是 RAID 卡 有 
电池 备份 单元 。 为 了 确保 电池 的 有 效 性 ，RAID 卡 会 定期 检查 电池 状 
态 ， 并 在 电池 电量 不 足 时 对 其 进行 充电 ， 在 充电 的 这 段 时 间 内 会 将 
Write Back 功 能 切换 为 最 为 安全 的 Write Through。 


用 户 可 以 在 没有 电池 备份 单元 的 情况 下 强制 启用 Write _ Back 功能， 
也 可 以 在 电池 充电 时 强制 使 用 Write Back 功 能， 只 是 写 入 是 不 安全 的 。 
用 户 应 该 非常 确信 这 点 ， 人 否则 不 应 该 在 没有 电池 备份 单元 的 情况 下 局 用 
Write Back。 




















可 以 通过 插入 20W 的 记录 来 比较 Write Back 和 Write Through 的 性 能 
差异 : 


mysql>CREATE TABLE t(a CHAR(2))Engine-InnoDB; 
y " OW. fected(0.00 sec) 
mysql>DELIMITER// 


m 
mysql- CREATE PROCEDURE p() 
7 BEGIN 


->DECLARE v INT; 
->SET v=0; 
->WHILE v<200000 
a t tee a'); 
oa WATLE. 
->END 

a 

Query OK, 0 affected(0.12 sec) 
mys AL >DELTMITER; 


首先 创建 一 个 向 表 t 插 入 20W 记 录 的 存储 过 程 ， 并 在 Write Backfill 
Write Through 的 设置 下 分 别 进行 测试 ， 最 终 测 试 结果 如 表 9-2 所 示 。 


$02. Wie Back Wie Through BR o eg 


RAD FRE H 
Write Back pi 
Wrte Through 18 
Write Through with modb Aush og at trx commi 0j 


由 于 批量 插入 不 是 在 一 个 事务 中 完成 的 ， 而 是 直接 用 命令 CALL P 
来 运行 的 ， 因 此 数据 库 实际 执行 了 20W 次 的 事务 。 很 明显 可 以 看 到 ， 在 
Write Back 模 式 下 执行 时 间 只 需要 43 秒 ， 而 在 Write _ Through 模式 下 执行 
时 间 需 要 31 分 钟 ， 大 约 有 40 多 倍 的 差距 。 


当然 ， 在 Write Through 模 式 下 ， 通 过 将 参数 
innodb_flush_log_at_trx_commit 设 置 为 0 也 可 以 提高 执行 存储 过 程 P 的 性 
能 ， 这 时 只 需要 68 秒 了 。 因 为 ， 在 此 设置 下 ， 重 做 日 志 的 写 入 不 是 发 生 
在 每 次 事务 提交 时 ， 而 是 发 生 在 后 台 master 线 程 每 秒 钟 自动 刷新 的 时 
候 ， 因此 减少 了 物理 磁盘 的 写 入 请 求 ， 所 以 执行 速度 也 可 以 有 明显 的 提 


高 。 














9.4.3 ”RAID 配置 工具 


对 RAID 卡 进行 配置 可 以 在 服务 器 启动 时 进入 一 个 类 似 于 BIOS 的 配 
置 界面 ， 然 后 再 对 其 进行 各 种 设置 。 此 外 ， 很 多 厂商 都 开发 了 各 种 操作 
系统 下 的 软件 对 RAID 进 行 配置 ， 如 果 用 户 使 用 的 是 LSI 公 司 生 产 提 供 的 
RAID 卡 ， 则 可 以 使 用 MegaCLI 工 具 来 进行 配置 。 


MegaCLI 为 多 个 操作 系统 提供 了 文 持 ， 对 Windows 操 作 系 统 还 提供 
了 GUI 界面 的 配置 环境 ， 因 此 相对 来 说 比较 简单 。 这 里 主要 介绍 命令 行 
下 MegaCLI 的 使 用 ， 在 Windows 下 同样 可 以 使 用 命令 MegaCLI.exe。 


使 用 MegaCLI 查 看 RAID 卡 的 信息 : 





[root@xen-server~]#/0pt/MegaRAID/MegaCli/MegaCcli64-AdpAllInfo-a0 
Adapter#0 
Versions 





Product Name:MegaRAID SAS 8708ELP 
Serial No:P012233608 
FW Package Build:9.0.1-0030 





SAS Address :500605b000d1e180 
BBU: Present 

Alarm:Present 

NVRAM: Present 

Serial Debugger :Present 
Memory:Present 

Flash:Present 

Memory Size:256MB 

TPM: Absent 

Default Settings 


Phy Polarity:0 
PhyPolaritySplit : 240 

Background Rate:30 

Stripe Size:64kB 

Flush Time:4 seconds 

Write Policy:WB 

Read Policy:None 

Cache When BBU Bad:Disabled 
Cached I0:No 

SMART Mode:Mode 6 

Alarm Disable:Yes 

Coercion Mode:1GB 

ZCR Config:Unknown 

Dirty LED Shows Drive Activity:No 
BIOS Continue on Error:No 

Spin Down Mode:None 

Allowed Device Type:SAS/SATA Mix 
Allow Mix in Enclosure:Yes 

Allow HDD SAS/SATA Mix in VD:Yes 
Allow SSD SAS/SATA Mix in VD:No 
Allow HDD/SSD Mix in VD:No 

Allow SATA in Cluster:No 

Max Chained Enclosures:3 

Disable Ctrl-R:Yes 

Enable Web BIOS:Yes 

Direct PD Mapping:No 

BIOS Enumerate VDs:Yes 

Restore Hot Spare on Insertion:No 
Expose Enclosure Devices: Yes 
Maintain PD Fail History:Yes 
Disable Puncturing:No 

Zero Based Enclosure Enumeration:No 
PreBoot CLI Enabled:Yes 

LED Show Drive Activity:No 
Cluster Disable:Yes 

SAS Disable:No 

Auto Detect BackPlane Enable:SGPIO/i2c SEP 


Use FDE Only:No 
Enable Led Header:No 
Delay during POST:0 





由 于 排版 的 原因 ， 这 里 只 列 出 了 和 输出 的 一 小 部 分 。 通 过 上 述 命 令 可 
以 看 到 RAID 卡 的 一 些 硬件 设置 ， 如 这 块 RAID 卡 的 型 号 是 MegaRAID 
SAS 8708ELP， 缓 存 大 小 是 256MB 。 还 可 以 看 到 一 些 默认 的 配置 ， 如 默 
认 启 用 的 Write Policy 为 WB (Write Back) 等 。 


MegaCLI 还 可 以 用 来 查看 当前 物理 磁盘 的 信息 ， 如 : 





[root@xen-server~]#/opt/MegaRAID/MegaCli/MegaCli64-PDList-aALL 
Adapter#0 

Enclosure Device ID:252 

Slot Number:0 

Device Id:8 

Sequence Number :2 

Media Error Count:0 

Other Error Count:0 

Predictive Failure Count:0 

Last Predictive Failure Event Seq Number:0 

PD Type :SAS 

Raw Size:279.396 GB[0x22ecb25c Sectors] 

Non Coerced Size:278.896 GB[0x22dcb25c Sectors] 
Coerced Size:278.464 GB[0x22cee000 Sectors] 
Firmware state:Online 

SAS Address(0):0x5000c5000f 363b55 

SAS Address(1):0x0 

Connected Port Number:0(pathO) 

Inquiry Data:SEAGATE ST3300655SS 00023LM5MGZZ 
FDE Capable:Not Capable 

FDE Enable:Disable 

Secured:Unsecured 

Locked:Unlocked 

Foreign State:None 

Device Speed:Unknown 

Link Speed:Unknown 

Media Type:Hard Disk Device 





可 以 看 到 当前 使 用 的 磁盘 型 号 是 SEAGATE ST3300655SS。 可 以 从 
这 个 型 号 继续 找到 这 个 硬盘 的 具体 信息 ， 如 在 希捷 官网 
http://discountechnology.com/Seagate-ST3300655SS-SAS-Hard-Drive 上 可 
以 知道 这 块 硬 盘 大 小 是 3.5 寸 的 ， 转 速 为 15 000， 人 硬盘 的 Cache 为 16MB， 
随机 读 取 的 寻 道 时 间 是 3.5 坚 秒 ， 随 机 写 入 的 寻 道 时 间 是 4.0 坚 秒 等 。 


此 外 ， 还 可 以 通过 下 面 的 命令 来 查看 是 否 开局 了 Write Back 功 能 : 




















[rootQxen-server —]4/opt/MegaRAID/MegaCli/MegaCli64-LDGetProp-Cache-LALL -aALL 

Adapter 0-VD O(target id:0):Cache Policy:WriteBack,ReadAheadNone,Direct,No Write Cache if bad BBU 
Adapter 0-VD 1(target id:1):Cache Policy:WriteBack,ReadAheadNone,Direct,No Write Cache if bad BBU 
Exit Code:0x00 





通过 上 面 的 结果 可 以 发 现 当 前 开启 了 RAID 卡 的 Write Back 功 能 ， 并 
且 当 BBU 有 问题 时 或 在 充电 时 禁用 Write Back 功 能。 此 外 ， 这 里 还 显示 
了 不 需要 启用 RAID 卡 的 预 读 功 能 ， 写 入 方式 为 直接 写 入 。 


通过 下 面 的 命令 可 以 对 当前 的 写 入 策略 进行 调整 : 





#/opt/MegaRAID/MegaCli/MegaC1i64-LDSetPropWB-LALL-aALL 
#/opt /MegaRAID/MegaCli/MegaC1i64-LDSetPropWT-LALL-aALL 





特别 需要 注意 地 是 ， 当 RAID 卡 的 写 入 策略 从 Write Back 切 换 为 
Write _ Through 时 ， 该 更 改 立 即 生效 。 然 而 从 Write _ Through 切换 为 Write 
Back 时 ， 必 须 重 局 服务 器 才能 使 其 生效 。 


9.5 ”操作 系统 的 选择 


Linux 是 MySQL 数 据 库 服 务 需 中 最 常 使 用 的 操作 系统 。 与 其 他 操作 
系统 不 同 的 是 Linux 有 着 众多 的 发 行 版 本 ， 每 个 用 户 的 偏好 可 能 不 尽 相 
同 。 然 而 在 将 Linux 操 作 系统 作为 数据 库 服务 器 时 需要 考虑 更 多 的 是 操 
作 系 统 的 稳定 性 ， 而 不 是 新 特性 。 


除了 Linux 操 作 系 统 外 ，FreeBSD 也 是 男 一 个 常见 的 优秀 操作 系统 。 
之 前 版 本 的 FreeBSD 对 MySQL 数 据 库 文 持 得 不 是 很 好 ， 需 要 选择 单独 的 
线程 库 进 行 手动 编译 ， 但 是 新 版 本 的 FreeBSD 对 MySQL 数 据 库 的 支持 已 
经 好 了 很 多 ， 直 接 下 载 二 进 制 安装 包 即 可 。 


Solaris 也 是 非常 不 错 的 操作 系统 ， 之 前 是 基于 SPARC 硬 件 的 操作 系 
统 ， 现 在 已 经 移植 到 了 X86 平台 上 。Solaris 是 高 性 能 、 高 可 靠 性 的 操作 
系统 ， 同 时 其 提供 的 ZFS 文 件 系统 非常 适合 MySQL 的 数据 库 应 用 。 如 果 
需要 ， 用 户 可 以 尝试 它 的 开源 版 本 Open Solaris. 


Windows 操 作 系 统 在 MySQL 数 据 库 应 用 中 也 非常 普及 。 也 有 公司 喜 
欢 在 开发 环境 下 使 用 Windows 版 本 的 MySQL 数 据 库 ， 而 在 正式 生产 环境 
下 选择 使 用 Linux 操 作 系 统 。 这 本 身 没 有 什么 问题 ， 但 问题 通常 存在 于 
文件 系统 大 小 写 敏感 对 应 用 程序 的 影响 。 在 Windows 操 作 系 统 下 表 名 不 
区 分 大 小 写 ， 而 Linux 操 作 系 统 却 是 大 小 写 敏 感 的 ， 这 点 在 开发 阶段 需 


要 特别 注意 。 


4G 内 存在 当前 已 经 非常 普遍 了 ， 即 使 是 桌面 用 户 也 开始 使 用 8G 的 
内 存 。 为 了 可 以 更 好 地 使 用 大 于 4G 的 内 存 容量 ， 用 户 必 须 使 用 64 位 的 
操作 系统 ， 上 述 介绍 的 这 些 操作 系统 都 提供 了 64 位 的 版 本 。 此 外 ， 使 用 
64 位 的 操作 系统 还 必须 使 用 64 位 的 软件 。 这 听 上 去 像 是 名 废话， 但 是 我 
曾 多 次 看 到 32 位 的 MySQL 数 据 库 安装 在 64 位 的 系统 上 ， 导 致 不 能 充分 
发 挥 64 位 操作 系统 的 内 存 寻 址 能 力 。 





























9.6 不 同 的 文件 系统 对 数据 库 性 能 的 影响 


每 个 操作 系统 都 默认 文 持 一 种 文件 系统 并 推荐 用 户 使 用 ， 如 
Windows 默 认 文 持 NTFS，Solaris 默 认 文 持 ZFS。 而 对 于 Linux 这 样 的 操作 
系统 ， 不 同 发 行 版 本 默认 文 持 的 文件 系统 各 不 相同 ， 有 的 默认 文 持 
EXT3， 有 的 是 ReiserFS， 有 的 是 EXT4， 有 的 是 XFS。 


虽然 不 同 特性 的 文件 系统 有 很 多 ， 但 是 在 实际 使 用 过 程 中 从 未 感觉 
到 文件 系统 的 性 能 差异 有 多 大 。 网 上 有 多 个 关于 XFS 文件 系统 的 “ 神 
话 ”， 认 为 其 是 多 么 地 适合 数据 库 应 用 ， 性 能 较 之 EXT3 有 极 大 的 提升 。 
但 是 在 实际 测试 和 使 用 后 发 现 ， 它 的 性 能 和 EXT3 在 整体 上 没有 大 的 差 
下。 因此，DBA 首 先 应 该 把 更 多 的 注意 力 必 到 数据 库 上， 而 不 是 纠结 
文件 系统 。 


文件 系统 可 提供 的 功能 也 许 是 DBA 需 要 关注 的 ， 例 如 ZFS 文 件 系 统 
本 刁 就 可 以 文 持 快照 ， 因 此 惑 不 需要 LVM 这 样 的 逻辑 卷 管理 工具 。 此 
外 ， 可 能 还 需要 知道 mount 的 参数 ， 这 些 参数 在 每 个 文件 系统 中 可 能 有 
所 不 同 。 








9.7 选择 合适 的 基准 测试 工具 

基准 测试 工具 可 以 用 来 对 数据 库 或 操作 系统 调 优 后 的 性 能 进行 对 
比 。MySQL 数 据 库 本 身 提 供 了 一 些 比较 优秀 的 工具 ， 这 里 将 介绍 另外 
两 款 更 为 优秀 和 常用 的 基准 测试 工具 : sysbench 和 mysql-tpcc。 
9.7.1 sysbench 


sysbench 是 一 个 模块 化 的 、 跟 平台 的 多 线程 基准 测试 工具 ， 主 要 用 
于 测试 各 种 不 同系 统 参 数 下 的 数据 库 负 载 情况 。 它 主要 包括 以 下 几 种 测 
AJIA: 

DCPU 性 能 

口 磁 盘 IO 性 能 

口 调度 程序 性 能 

口内 存 分 配 及 传输 速度 

口 POSIX 线 程 性 能 

口 数据 库 OLTP 基 准 测 试 

sysbench 的 数据 库 OLTP 测 试 文 持 MySQL、PostgreSQL 和 Oracle。 目 
前 sysbench 主 要 用 于 Linux 操 作 系 统 ， 开 源 社 区 已 经 将 sysbench 移 植 到 
Windows， 并 支持 对 Microsoft SQL Server 数 据 库 的 测试 。 

sysbench 的 官网 地 址 是 : http://sysbench.sourceforge.net， 可 以 从 该 地 
址 下 载 最 新 版 本 的 sysbench 工 具 ， 然 后 进行 编译 和 安装 。 此 外 ， 有 些 
Linux 操 作 系 统 发 行 版 本 ， 如 RED HAT， 本 身 可 能 已 经 提供 了 sysbench 
的 安装 包 ， 直 接 安装 即 可 。 


sysbench 可 以 通过 不 同 的 参数 设置 来 进行 不 同 项 目的 测试 ， 使 用 方 
法 如 下 : 








Usage: 
sysbench[general-options]...--test=<test-name>[test-options]...command 
General options: 

--num-threads=N number of threads to use[1] 

--max-requests=N limit for total number of requests[10000] 
--max-time=N limit for total execution time in seconds[0] 
--thread-stack-size-SIZE size of stack per thread[32K] 
--init-rng-[on|off]initialize random number generator[off] 
--test=STRING test to run 

--debug-[on|off]print more debugging info[off] 
--validate-[on|off]perform validation checks where possible[off] 
--help-[on|off]print help and exit 

--version-[on|off]print version and exit 

Compiled-in tests: 

fileio-File I/O test 

cpu-CPU performance test 

memory-Memory functions speed test 

threads-Threads subsystem performance test 

mutex-Mutex performance test 

oltp-OLTP test 

Commands:prepare run cleanup help version 
See'sysbench--test=<name>help'for a list of options for each test. 





对 于 InnoDB 存 储 引 擎 的 数据 库 应 用 来 说， 用 户 可 能 更 关心 磁盘 和 
OLTP 的 性 能 ， 因 此 主要 测试 fleio 和 oltp 这 两 个 项 目 。 对 于 磁盘 的 测试 ， 
sysbench 提 供 了 以 下 的 测试 选项 : 





[root@xen-server~]#sysbench--test=fileio help 

sysbench 0.4.10:multi-threaded system evaluation benchmark 

fileio options: 

--file-num=N number of files to create[128] 

--file-block-size=N block size to use in all IO operations[16384] 

--file-total-size-SIZE total size of files to create[26] 

--file-test-mode-STRING test mode[seqwr,seqrewr, seqrd, rndrd, rndwr, rndrw} 
--file-io-mode-STRING file operations mode{sync, async, fastmmap, slowmmap}[sync] 
--file-extra-flags-STRING additional flags to use on opening files{sync,dsync, direct}[] 
--file-fsync-freq=N do fsync()after this number of requests(0-don't use fsync())[100] 
--file-fsync-all=[on|off]do fsync()after each write operation[off] 
--file-fsync-end-[on|off]do fsync()at the end of test[on] 

--file-fsync-mode-STRING which method to use for synchronization{fsync, fdatasync}[fsync] 
--file-merged-requests=N merge at most this number of IO requests if possible(0-don't merge)[0] 
--file-rw-ratio=N reads/writes ratio for combined test[1.5] 





各 个 参数 的 含义 如 下 : 

口 --file-num， 生 成 测试 文件 的 数量 ， 默 认为 128。 

口 --file-block-size， 测 试 期 间 文 件 块 的 大 小 ， 如 果 想 知道 磁盘 针对 
InnoDB 存 储 引擎 进行 的 测试 ， 可 以 将 其 设置 为 16384， 即 InnoDB 存 储 引 
擎 页 的 大 小 。 默 认为 16384。 

口 --file-total-size， 每 个 文件 的 大 小 ， 默 认为 2GB。 

口 --file-test-mode， 文 件 测试 模式 ,包含 seqwr (顺序 写 ) ~ 
seqrewr( 顺 序 读 写 ) . seqrd (顺序 读 ) 、mdrd( 随 机 读 ) ~ mdwr CB 
HLS) 和 mdrw (随机 读 写 ) 。 


口 --file-io-mode， 文 件 操作 的 模式 ， 同 步 还 是 异步 ， 或 者 是 选择 
MMAP (map 映 射 ) 模式。 默认 为 同步 。 


口 --file-extra-flags， 打 开 文 件 时 的 选项 ， 这 是 与 API 相 关 的 参数 。 


口 --file-fsync-freq， 执 行 fsync 疯 数 的 频率 。fsync 主 要 是 同步 磁盘 文 
件 ， 因 为 可 能 有 系统 和 磁盘 绥 冲 的 关系 。 


口 --file-fsync-all， 每 执行 完 一 次 写 操作 ， 就 执行 一 次 fsync。 默 认为 
off. 


口 --file-fsync-end， 在 测试 结束 时 ， 执 行 fync。 默 认为 on。 

口 --file-fsync-mode， 文 件 同 步 函 数 的 选择 ， 同 样 是 和 API 相 关 的 参 
数 ， 由 于 多 个 操作 系统 对 fdatasync 支 持 的 不 同 ， 因 此 不 建议 使 用 
fdatasync。 默 认为 fsync。 


口 --file-rw-ratio， 测 试 时 的 读 写 比例 ， 默 认 是 2 : 1。 





sysbench 的 feio 测 试 需要 经 过 prepare、run 和 cleanup 三 个 阶段 。 
prepare 是 准备 阶段 ， 生 产 需 要 的 测试 文件 ，run 是 实际 测试 阶段 ， 
cleanup 是 清理 测试 产生 的 文件 。 例 如 进行 16 个 文件 、 总 大 小 2GB 的 fileio 
测试 : 





[root@xen-server ssd]#sysbench- -test=fileio--file-num=16--file-total-size=2G prepare 
sysbench 0.4.10:multi-threaded system evaluation benchmark 

16 files,131072Kb each,2048Mb total 

Creating files for the test... 





接着 在 相应 的 目录 下 就 会 产生 16 个 文件 ， 因 为 总 大 小 是 2GB， 所 以 
每 个 文件 的 大 小 应 该 是 128MB。 





[root@xen-server ssd]#ls-lh 
total 2G 


-fW------- 1 root root 128M Aug 12 10:42 test file.O 
-fW------- 1 root root 128M Aug 12 10:42 test file.1 
-fW------- 1 root root 128M Aug 12 10:42 test file.10 
-fW------- 1 root root 128M Aug 12 10:42 test file.11 
-fW------- 1 root root 128M Aug 12 10:42 test file.12 
-fW------- 1 root root 128M Aug 12 10:42 test file.13 
-fW------- 1 root root 128M Aug 12 10:42 test file.14 
-fW------- 1 root root 128M Aug 12 10:42 test file.15 
-fW------- 1 root root 128M Aug 12 10:42 test file.2 
-fW------- 1 root root 128M Aug 12 10:42 test file.3 
-fW------- 1 root root 128M Aug 12 10:42 test file.4 
-fW------- 1 root root 128M Aug 12 10:42 test file.5 
-fW------- 1 root root 128M Aug 12 10:42 test file.6 
-fW------- 1 root root 128M Aug 12 10:42 test file.7 
-fW------- 1 root root 128M Aug 12 10:42 test file.8 
-fW------- 1 root root 128M Aug 12 10:42 test file.9 














接 痢 就 可 以 基于 这 些 文件 进行 测试 了 了 。 下 面 是 在 16 个 线程 下 的 随机 





[root@xen-server ssd]#sysbench--test=fileio--file-total-size=2G- -file-test-mode=rndrd- -max-time=180- -max- 
requests=100000006- -num- threads=16 - - init -rng=on- - file-num=16- -file-extra-flags=direct - -file-fsync-freq=0--file-block-size=16384 
run 





上 述 测试 的 最 大 随机 读 取 请 求 是 100 000 000 次 ， 如 果 在 180 秒 内 不 
能 完成 ， 测 试 即 结束 。 测 试 结束 后 可 以 看 到 如 下 的 测试 结果 : 





[root@xen-server ssd]£sysbench--test-fileio--file-total-size-2G--file-test-mode-rndrd--max-time-180- -max- 
requests-100009000--num-threads-16--init-rng-zon--file-num-16--file-extra-flags-direct--file-fsync-freq-0--file-block-size-16384 
run 

sysbench 0.4.10:multi-threaded system evaluation benchmark 

Running the test with following options: 

Number of threads:16 

Initializing random number generator from timer. 

Extra file open flags:16384 

16 files,128Mb each 

2Gb total file size 

Block size 16Kb 

Number of random requests for random I0:100000000 

Read/Write ratio for combined random IO test:1.50 

Calling fsync()at the end of test,Enabled. 

Using synchronous I/O mode 

Doing random read test 

Threads started! 

Time limit exceeded,exiting... 

(last message repeated 15 times) 

Done. 

Operations performed:619908 Read,O Write,9 Other=619908 Total 

Read 9.459Gb Written 0b Total transferred 9.459Gb(53.81Mb/sec) 

3443.85 Requests/sec executed 

Test execution summary: 

total time:180.0044s 

total number of events:619908 

total time taken by event execution:2878.0750 

per-request statistics: 

min:0.42ms 

avg:4.64ms 

max:27.30ms 

approx.95 percentile:8.13ms 

Threads fairness: 

events(avg/stddev) :38744.2500/102.69 

execution time(avg/stddev) :179.8797/0.00 





可 以 看 到 随机 读 取 的 性 能 为 53.81MB/s， 随 机 读 的 IOPS 为 3443.85。 
测试 的 硬盘 是 固态 硬盘 ， 因 此 随机 读 取 的 性 能 较为 强劲 。 此 外 还 可 以 看 
到 每 次 请 求 的 一 些 具 体 数 据 ， 如 最 大 值 、 最 小 值 、 平 均值 等 。 


测试 结束 后 ， 记 得 要 执行 ceanup， 确 保 测 试 产生 的 文件 都 已 删除 : 








[root@xen-server ssd]#sysbench--test=fileio--file-num=16--file-total-size=2G cleanup 
sysbench 0.4.10:multi-threaded system evaluation benchmark 
Removing test files... 





可 能 用 户 需 要 测试 随机 读 、 随 机 写 、 随 机 读 写 、 顺 夺 写 、 顺 序 读 等 
所 有 这 些 模式 ， 并 且 还 可 能 需要 测试 不 同 的 线程 和 不 同文 件 块 下 磁盘 的 
性 能 表现 ， 这 时 可 能 需要 类 似 如 下 的 脚本 来 帮 用 户 目 动 完成 这 些 测试 : 











#!/bin/sh 
set-u 
set-x 


set-e 

for size in 8G 646;do 

for mode in seqrd seqrw rndrd rndwr rndrw;do 

for blksize in 4096 16384;do 
sysbench--test-fileio--file-num-64--file-total-size-$size prepare 
for threads in 1 4 8 16 32;do 





echo PARAMS$size$mode$threads$blksize>sysbench-size-$size-mode-$mode-threads-$threads-blksz-$blksize 
for i in 1 2 3;do 

sysbench- -test=fileio--file-total-size=$size--file-test-mode=$mode\ 
--max-time-180--max-requests-100000000--num-threads-$threads--init-rng-onN 
--file-num-z64--file-extra-flags-direct--file-fsync-freq-0--file-block-size-$blksize run\ 
|tee-a sysbench-size-$size-mode-$mode-threads-$threads-blksz-$blksize 27 &1 

done 

done 

sysbench--test-fileio--file-total-size-$size cleanup 

done 

done 

done 





对 于 MySQL 数 据 库 的 OLTP 测 试 ， 和 fileio 一 样 需要 经 历 prepare、 
run 和 cleanup 阶 段 。prepare 阶 段 会 根据 选项 产生 一 张 指定 行 数 的 表 ， 默 
认 表 在 sbtest 架 构 下 ， 表 名 为 sbtest (sysbench 默 认 生成 表 的 存储 引擎 为 
InnoDB) 。 例 如 创建 一 张 8000W 的 表 : 





[root@xen-server ~ ]#sysbench- -test=oltp--oltp-table-size=80000000- -db-driver-mysql--mysql-socket-/tmp/mysql.sock--mysql- 
user=root prepare 

sysbench 0.4.10:multi-threaded system evaluation benchmark 

Creating table'sbtest'... 

Creating 80000000 records in table'sbtest'... 








BE UR] ARTET ERRET oltp HY JU: 





sysbench--test=oltp--oltp-table-size=80000000- -oltp-read-only=off - - init - rng=on- -num-threads=16 - -max-requests=0--oltp- 
dist -type=uniform- -max-time=3600- -mysql-user=root - -mysql-socket=/tmp/mysql.sock--db-driver=mysql run>res 





用 户 可 将 测试 结果 放 入 到 了 文件 res 中 ， 但 看 res 可 得 类 似 如 下 结 
果 : 





sysbench 0.4.10:multi-threaded system evaluation benchmark 
WARNING:Preparing of"BEGIN"is unsupported,using emulation 
(last message repeated 15 times) 

Running the test with following options: 

Number of threads:16 

Initializing random number generator from timer. 
Doing OLTP test. 

Running mixed OLTP test 

Using Uniform distribution 

Using"BEGIN"for starting transactions 

Using auto inc on the id column 

Threads started! 

Time limit exceeded,exiting... 

(last message repeated 15 times) 

Done. 

OLTP test statistics: 

queries performed: 

read:6043324 

write:2158330 

other:863332 

total:9064986 

transactions:431666(119.90 per sec.) 
deadlocks:0(0.00 per sec.) 

read/write requests:8201654(2278.07 per sec.) 
other operations:863332(239.80 per sec.) 

Test execution summary: 


total time:3600.2672s 

total number of events:431666 

total time taken by event execution:57598.5965 
per-request statistics: 

min:6.84ms 

avg:133.43ms 

max:7155.61ms 

approx.95 percentile: 325.84ms 

Threads fairness: 

events(avg/stddev) :26979.1250/64.14 
execution time(avg/stddev) :3599.9123/0.06. 





结果 中 罗列 出 了 测试 时 很 多 操作 的 详细 信息 ，transactions 代 表 了 测 
试 结果 的 评判 标准 ， 即 TPS， 上 述 测试 的 结果 是 119.9tps。 用 户 可 以 对 数 
据 库 进行 调 优 后 再 运行 sysbench 的 OLTP 测 试 ， 看 看 TPS 是 否 有 所 提高 。 
Ee sysbench 的 测试 只 是 基准 测试 ， 并 不 代表 实际 生产 环境 下 的 性 能 
HR 。 








9.7.2 mysql-tpcc 


TPC (Transaction Processing Performance Council， 事 务 处 理性 能 协 
Z) 是 一 个 用 来 评价 大 型 数据 库 系 统 软 硬 件 性 能 的 非 盘 利 组 织 。ITPC-C 
是 TPC 协 会 制定 的 ， 用 来 测试 典型 的 复杂 OLTP 在 线 事务 处 理 ) 系统 
的 性 能 。 目 前 在 学 术 界 和 工业 界 普 人 裔 采用 TPC-C 来 评价 OLTP 应 用 的 性 


eu 
HE o 


TPC-CHI3NF (第 三 范式 ) 虚拟 实现 了 一 家 仓库 销售 供应 商 公 司 ， 
拥有 一 批 分 布 在 不 同 地 方 的 仓库 和 地 区 分 公司 。 当 公司 业务 扩大 时 ， 将 
建立 新 的 仓库 和 地 区 分 公司 。 通 常 每 个 仓库 供 货 覆盖 10 家 地 区 分 公司 ， 
每 个 地 区 分 公司 服务 3000 名 客户 。 公 司 共有 100 “000 种 商品 ， 分 别 储存 
在 各 个 仓库 中 。 该 系统 包含 了 库存 管理 、 销 售 、 分 发 产品 、 付 款 、 订 单 
查询 等 一 系列 操作 ， 一 共 包 含 了 9 个 基本 关系 ， 基 本 关系 如 图 9-9 所 示 。 
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Ò s dist, 07 CHAR(24) Indexes © d, ytd DECIMAL(12,2) 
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* € jd INT(L1) 

! c. d jd TINYINT(4) 
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9 c last VARCHAR(16) 
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: 0. d id TINVINT(4) © c, zip CHAR(9) 
ciues : 0. w id SMALLINT(6) © c phone CHAR(16) 
- $0 c d INTL) 9 c, since DATETIME 
Ede oo enry dDATETIME P © c credi CHAR(2) 
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Ò C, ytd payment DECIMAL(12,2) 


€ payment, cnt SMALLINT(6) 
© ¢ delivery. cnt SMALLINT(6) 
© c data TEXT 


Indexes 
: no o id INT(11) 


` no, d id TINVINT(4) 
' no. w id SMALLINT(6) 


图 9-9 TPC-C 基 本 关系 图 


TPC-C 的 性 能 度量 单位 是 tpmC，tpm 是 transaction per a 
写 ，C 代 表 TPC 的 C 基 准 测 试 。 该 值 越 大 ， 代 表 事 务 处 理 的 性 能 越 高 。 


De -mysql 丰 开源 的 TPC-C 测 斌 工具， 该 测试 工具 完全 遵守 TPC-C 的 
标准 。 其 官方 网 站 为 : https:Wcode.launchpad.net/ 一 percona- 
dev/perconatools/tpcc-mysql。 之 前 tpcc-mysql 主 要 工作 在 Linux 操 作 系 统 
上 ， 我 已 经 将 其 移植 到 了 Windows 平 台 ， 可 以 在 
http://code.google.com/p/david-mysql-tools/downloads/list F #%2!/Windows 
版 本 的 tpcc-mysql。 

tpcc-mysql 由 以 下 两 个 工具 组 成 。 

Dtpcc_load: 根据 仓库 数量 ， 生 成 9 张 表 中 的 数据 。 

Dtpcc_start: 根据 不 同 选项 进行 TPC-C 测 试 。 


tpcc_load 命 令 的 使 用 方法 如 下 : 











[root@xen-server~]#tpcc_load 


FRI KK ko koe koe koe ke ke koe koe e ko koe k de ko ke e e 


eee eee ee ee ee ee ek ek ee dee ke ke dee de ke e e 


usage: tpcc_load[server ] [DB] [user] [pass] [warehouse] 
OR 


tpec_ ee ee I [pass] eer eure [part] [min wh] [max wh] 
*[part]:1-ITEMS 2-WAREHOUSE 3=CUSTOMER 4=ORDE 





各 参数 的 意义 如 下 : 

Dserver， 导 入 的 MySQL 服 务 器 IP。 
DDB， 导 入 的 数据 库 。 
Duser，MySQL 的 用 户 名 。 
Dpass，MySQL 的 密码 。 

口 warehouse， 要 生产 的 仓库 数量 。 


如 果 用 tpcc_load 工 具 创 建 100 个 仓库 的 数据 库 tpcc， 可 以 这 样 : 





root@xen-server tpcc-mysql]#mysql tpcc<create_table.sql 
root@xen-server tpcc-mysql]#mysql tpcc<add_fkey_idx.sql 
root@xen-server tpcc-mysql]#tpcc_load 127.0.0.1 tpcc2 root xxxxxx 100 


FR IK OK IK IK OK IK IK koe KR OK IO KR KICK 


***iHHteasytHttTPC-C Data Loader*** 

FE HE HE HE HE HE FEE EE E E E KE KE FE FE FE TO IOUT TOTO ITO K 
<Parameters> 

server]:127.0.0.1 

DBname]:tpcc2 

user]:root 

pass]: 

warehouse]:100 

TPCC Data Load Started... 

Loading Item 





-. DATA LOADING COMPLETED SUCCESSFULLY. 





tpcc_start 命 令 的 使 用 方法 如 下 : 





[root@xen-server~]#tpcc_start 


TR IK OK IO koe koe koe koe k TOK IO KOK TOR KR OR de RR 


***iHHteasytHtHtTPC-C Load Generator*** 


Ok IK ok IO koe koe koe I OK TOR I koe koe ke koe ke ek de RR 


usage:tpcc start[server][DB][user] [pass] [warehouse] [connection][rampup] [measure] 





相关 参数 的 作用 如 下 : 

Dconnection， 测 试 时 的 线程 数量 。 

Drampup， 热 届时 间 ， 单 位 秒 ， 这 上段 时 间 的 操作 不 计 入 统计 信息 。 
Dmeasure， 测 试 时 间 ， 单 位 秒 。 


如 使 用 tpcc_start 进 行 16 个 线程 的 测试 ， 热 届时 间 为 10 分 钟 ， 测 试 时 
间 为 20 分 钟 ， 如 下 : 





root@xen-server~]#tpcc_start 127.0.0.1 tpcc root xxxxxx 100 16 600 1200 


Ok IR TOK I ko ke koe koe I TOK TOK IO ko koe ko ke ek de RR 


***iHHteasytHttTPC-C Load Generator*** 
JOE III IIIT TTI ROG GGG GR GE 
<Parameters> 

server]:127.0.0.1 

DBname]:tpcc 

user]:root 

pass]: xxxxxx 

warehouse]:100 

connection]:16 

rampup]:600(sec.) 
measure]:1200(sec.) 








在 测试 的 时 候 用 户 或 许 会 在 终端 上 看 到 类 似 如 下 的 输出 : 





RAMP-UP TIME.(1 sec.) 

MEASURING START. 
10,624(0):0.4,624(8):0.2,62(0):0.2,63(0):0.6,62(0):0.8 
20,990(0):0.2,988(0):0.2,98(0):0.2,99(0):0.4,98(0):0.6 
30,1435(0) :0.2,1436(0):0.2,144(0):0.2,143(0):0.2,144(0) :0.4 
40,1736(0):0.2,1739(0):0.2,174(0):0.2,174(0) :0.2,174(0):0.4 


50, 2041(0) :0.2,2044(0) :0.2,204(0) :0.2,204(0):0.2,207(0):0.2 
60,2195(0):0.2,2193(0):0.2,220(0):0.2,221(0):0.2,218(0):0.2 
70,2332(0):0.2,2335(0):0.2,233(0):0.2,232(0):0.2,234(0):0.2 
80,2408(0) :0.2,2401(0):0.2,241(0):0.2,239(0):0.2,241(0):0.2 
90, 2473(0) :0.2,2476(0) :0.2,247(0) :0.2,250(0):0.2,248(0):0.2 
100, 2350(0) :0.2, 2347(0) :0.2, 235(0) :0.2,233(0) :0.2, 235(0) :0.2 





这 些 信息 是 每 10 秒 TPC-C 测 试 的 结果 数据 ，TPC-C 测 试 一 共 测试 5 个 
模块 ， 分 别 是 New Order、Payment、Order-Status、Delivery、Stock- 
Level。 第 一 个 值 即 为 New Order， 这 也 是 TPC-C 测 试 结果 的 一 个 重要 考 
量 标准 New Order Per 10 Second (每 十 秒 订 单 处 理 能 力 )， 可 以 将 测试 
时 所 有 的 数据 组 成 一 张 折线 图 或 散 点 图 ， 观 察 InnoDB 存 储 引 擎 每 10 秒 
的 性 能 表现 ， 如 图 9-10 所 示 。 
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图 9-10 New Order Per 10 Second 
Mtpcc_loadix a ARN “EM tpmCt ee New Order Per 10 


Second 来 进行 的 ， 首 先 求 出 New Order Per 10 Second 的 平均 值 ， 然 后 乘 
以 6， 得 到 的 就 是 最 终 的 tpmC。 


< Check>(all must be[OK]) 
[transaction percenta ge] 
yl 48%( >=43 . 0%) [OK] 
d :4.35%( >=4.0%) [OK] 
1 y:4.35%( >=4.0%) [OK 
k 1:4.35%(>=4.0%) [OK] 
[ p e(at le sed)] 


New-Order:99.72%[0K] 
Payment :99.95%[OK] 
Order-Status:99.93%[OK] 
Delivery:100.00%[OK] 
Stock-Level:100.00%[0K] 
<Tpmc> 

7949.942 Tpmc 


二 一 


9.8 j£ 


在 这 一 章 中 我 们 根据 InnoDB 存 储 引 警 的 应 用 特点 对 CPU、 内 存 、 硬 
盘 、 固 态 硬盘 、RAID 卡 做 了 详细 的 介绍 ， 相 信 只 有 通过 理解 InnoDB 存 
储 引 擎 的 应 用 场合 和 范围 才能 更 好 地 对 其 进行 调 优 。 最 后 ， 介 绍 了 两 个 
在 Linux 操 作 系 统 平台 下 常用 的 基准 测试 工具 sysbench 和 tpcc-mysql， 借 
助 这 两 个 工具 可 以 更 有 效 地 得 知 当 前 系统 的 负载 承受 能 力 ， 以 及 对 
MySQL 数 据 库 的 调 优 结果 进行 分 析 。 


310%  InnoDB4£fiá 5| EJ (C3 H s ERU 
调试 

InnoDB 存 储 引 擎 是 开源 的 ， 这 意味 着 用 户 可 以 获得 其 源 代码 并 查 

看 内 部 的 具体 实现 。 任 何 时 候 Why 都 比 What 重要 ， 通 过 研究 源 代码 可 以 

更 好 地 理解 数据 库 是 如 何 工作 的 ， 从 而 知道 如 何 使 数据 库 更 好 地 为 你 工 


作 。 如 果 你 有 一 定 的 编程 能 力 ， 完 全 可 以 对 InnoDB 人 存储 引擎 进行 扩 
展 ， 开 发 出 新 的 功能 模块 来 更 好 地 文 持 数据 库 应 用 。 








10.1 获取 InnoDB 存 储 引 擎 源 代 码 


InnoDB 存 储 引 擎 的 源 代码 被 包含 在 MySQL 数 据 库 的 源 代 码 中 ， 在 
MySQL 的 官方 网 站 ”上 下 载 MySQL 数 据 库 的 源 代码 即 可 ， 如 图 10-1 所 
Ze 


MySQL Community Server 5.1.49 


Select Platform: 


Source Code g den 


SuSE Linux Enterprise Server ver. 11 
(Architecture Independent), RPM Package 








(MySQL-community-5,1,49-1.sles11.src.rpm) 


Red Hat & Oracle Enterprise Linux 5 
(Architecture Independent), RPM Package 


(MySQL-community-5.1,49-1.rhel5.src.rpm) 


SuSE Linux Enterprise Server 10 (Architecture 
Independent), RPM Package 
(MySQL-community-5.1,49-1.sles10.src.rpm) 


Generic Linux (glibc 2.3) (Architecture 
Independent), RPM Package 


(MySQL-5.1.49-1.9libc23,src.rpm) 


SuSE Linux Enterprise Server 9 (Architecture 
Independent), RPM Package 
(MySQL-community-5.1,49-1.sles9.src.rpm) 


Red Hat & Oracle Enterprise Linux 4 
(Architecture Independent), RPM Package 


(MySQL-community-5.1.49-1.rhelá.src.rpm) 


Red Hat Enterprise Linux 3 (Architecture 
Independent), RPM Package 
(MySQL-community-5.1,49-1.rhel3.src.rpm) 


Generic Linux (Architecture Independent), 


Download 


MDS; 714c5f8bf4b1816008895164909298aa 


22,0M Download 


MDS; 8c386345d6374be174033£3a17d49a0b 


22,0M Download 


MDS: cazed7£15fae60331F40b0083847Fe39 


22.0M Download 


MDS: 40cb7b039953a174e9p9e0628111036f 


22.0M Download 


MD5: 9e171c70c474679200856021bb112353 


22.0M Download 


MDS; 837d2e9ffbe9109072fe22bcafa91788 


22.0M Download 


MDS: bcB55486bd2b4d5d029d7b6bba4d4361 


22,6M Download 





图 10-1 MySQL 源 代码 下 载 


可 以 看 到 ， 这 里 有 不 同 操作 系统 下 的 源 代 码 可 供 下载 ， 一 般 只 需 下 
载 Generic ”Linux 的 版 本 即 可 。 通 过 MySQL 官 网 首页 的 Download 链 接 可 
以 迅速 地 找到 GA 版 本 的 下 载 ， 但 是 如 果 想 要 下 载 目前 正在 开发 的 
MySQL 版 本 ， 如 MySQL 5.5.5〔 现 在 是 milestone 的 版 本 ， 离 GA 版 本 还 有 
很 长 的 开发 时 间 〉， 用 户 可 能 在 官网 找 了 很 久 都 找 不 到 链接 ， 这 时 只 要 
把 下 载 的 链接 从 www 换 到 dev 即 可 ， 如 
http://dev.mysql.com/downloads/mysql， 在 这 里 就 可 以 找到 开发 中 的 
MySQL 版 本 的 源 代码 了 ， 如 图 10-2 所 示 。 





Generally Available (GA) Releases ^ Development Releases 


MySQL Community Server 5.5.5 m3 


Select Platform: 


Source Code A Select 


Linux - Generic 2.6 (Architecture Independent), 
RPM Package 
(MySQL-5.5.5 m3-L.linux2.6.src.rpm) 





SuSE Linux Enterprise Server ver. 11 
(Architecture Independent), RPM Package 
(MySQL-5.5.5. m3-1.slesi1.src.rpm) 


Red Hat & Oracle Enterprise Linux 5 
(Architecture Independent), RPM Package 
(MySQL-5.5.5 m3-1.rhel5.src.rpm) 


SuSE Linux Enterprise Server 10 (Architecture 
Independent), RPM Package 
(MySQL-5.5,5 m3-1.slest0.src.rpm) 


Red Hat & Oracle Enterprise Linux 4 
(Architecture Independent), RPM Package 
(MySQL-5.5.5 m3-1.rhel4.src.rpm) 


Generic Linux (Architecture Independent), 
Compressed TAR Archive 


(mysql-5.5.5-m3,tar.qz) 


MDS: ca368£b09617420b2a0f3d325£2acc34 


MDS: e8al3ch62el846666367d211575£2£29 


MDS; dd01ca7e34be238d62eef cle3d4c3fc 


21.0M Download 


MDS: d5b5e453f40e4ecb35c2731f4caDab2b 


21.0M Download 


MDS; 013c635b2316250206284e565079dccc 


21.8M Download 


MDS; ad27£656106010c9346ffeca6de403fa 





图 10-2 MySQL 开 发 中 版 本 的 源 代 码 下 载 


单 击 *Download” 下 载 标签 后 可 以 进入 到 下 载 页 面 ， 当 然 ， 有 
mysql.com 账 号 的 用 户 可 以 进行 登录 ，MySQL 官 方 提供 了 大 量 的 镜像 用 
来 分 流下 载 ， 用 户 可 以 根据 所 在 的 位 置 选择 下 载 速 度 最 快 的 地 址 。 中 国 
用 户 一 般 可 以 在 “Asia” 这 里 镜像 下 载 ， 如 图 10-3 所 示 。 





Asia 
也 sPD Hosting, Israel 
® JAIST, Japan 


Internet Initiative Japan Inc., Japan 


' 
Lahore University of Management Sciences, Pakistan 


“Kyung Hee University Linux User Group, Republic of Korea 
ezNetworking Solutions Pte, Ltd., Singapore 

国 minortn (Taiwan Mirror), Taiwan 

M Providence University, Taiwan 

国 National Taiwan University, Taiwan 

ational Sun Yat-Sen University, Taiwan 

a Computer Center, Shu-Te University / Kaohsiung, Taiwan 





图 10-3 ”MySQL 亚洲 下 载 镜像 


如 果 下 载 的 文件 是 tar.gz 结 尾 的 文件 ， 可 以 通过 Linux 的 tar 命 令 ， 
Windows 的 WinRAR 工 具 来 进行 解压 ， 解 压 后 得 到 一 个 文件 夹 ， 其 中 包 


含 了 MySQL 数 据 库 的 所 有 源 代 码 。 源 代码 的 结构 如 图 10-4 所 示 。 


BUILD 
client 

cma ke 
CNTalceFiles 
cmd -line-utils 
contig 

d bug 

Docs 

extra 
include 
libmysal 
liibmysgql_r 


libmysqld 


libservices 
man 
mysql-test 
mysys 
netware 
packaging 
plugin 
pstack 
regex 
scripts 
sql 
sql-bench 
sql-commeon 
storage 
strings 
support-files 
J tests 
unittest 


vic 





图 10-4 MySQL 源 代码 目录 结构 
所 有 存储 引擎 的 源 代码 都 被 放 在 storage 的 文件 夹 下 ， 其 源 代 码 结构 
如 图 10-5 所 示 。 
| archive 
; blackhole 
; CSV 
. example 
| federated 
heap 
; ibmdb2i 


| innobase 


| myisam 


| myisammrg 

| perfschema 
| | Makefile.am 
|. | Makefile.in 





图 10-5 存储 引擎 源 代码 文件 夹 


可 以 看 到 所 有 存储 引擎 的 源 代码 都 在 这 里 ， 文 件 夹 名 一 般 就 是 存储 
引擎 的 名 称 ， 如 archive、blackhole、csv、fedorated、heap、ibmdb2i、 
myisam、innobase。 从 MySQL 5.5 版 本 开始 ，InnoDB Plugin 已 经 作为 默 


认 的 InnoDB 存 储 引 擎 版 本 ， 而 在 MySQL 5.1 的 源 代码 中 ， 应 该 可 以 看 到 
两 个 版 本 的 InnoDB 存 储 引 擎 源 代 码 ， 如 网 10-6 所 示 。 


, archive 

; blackhole 

j CSV 

, example 

, federated 

. heap 

; ibmdb2i 

; Innobase 

; innodb plugin 
; myisam 

| myisammrg 


, ndb 


. | Makefile.am 
| | Makefile.in 


| | mysql storage engine.cmake 








图 10-6 MySQL 5.1 存 储 引 擎 目录 结构 


可 以 看 到 有 innobase 和 innodb_plugin 两 个 文件 夹 ，innobase 文 件 夹 是 
日 的 mnoDB 存 储 引擎 的 源 代 码 ，innodb_plugin 文 件 夹 是 mnoDB Plugin 存 


储 引 擎 的 源 代 码 。 如 果 想 将 mnoDB Plugin 直接 静态 编译 到 MySQL 数 据 
库 中 ， 那 么 需要 删除 innobase 文 件 来， 再 将 innodb_plugin 文 件 夹 重 命名 
为 innobase。 





[链接 为 : http:/ www.mysql.com/downloads/mysql/ o 


10.2 ”InnoDB 源 代码 结构 


进入 InnoDB 存 储 引擎 的 源 代码 文件 夹 ， 应 该 可 以 看 到 如 图 10-7 所 示 
的 源 代 码 结构 。 下 面 介绍 一 些 主要 文件 夹 内 的 源 代 码 的 具体 作用 。 





ha 
handler 
ibuf 


include 


lock 


log 





图 10-7 InnoDB 存 储 引 擎 源 代 码 的 文件 夹 结构 
Dbtr: B+ 树 的 实现 。 
Dbuf: 缓冲 池 的 实现 ， 包 括 LRU 算 法 ，Flush 刷 新 算法 等 。 
Qdict: InnoDB 存 储 引擎 中 内 存 数 据 字典 的 实现 。 
Ddyn: InnoDB 存 储 引 擎 中 动态 数组 的 实现 。 
口 纪 ;InnoDB 存 储 引 擎 中 文件 数据 结构 以 及 对 文件 的 一 些 操作 。 
Dfsp: 可 以 理解 为 fle space， 即 对 InnoDB 存 储 引 擎 物理 文件 的 管 





JE, WO. DX. ES. 


Pe 


Oha: 哈 希 算法 的 实现 。 

Qhandler: 继承 于 MySQL 的 handler， 插 件 式 存储 引擎 的 实现 。 
Dibuf: 插入 缓冲 的 实现 。 

Dinclude: InnoDB 将 头 文件 Ch, ic) 文件 都 统一 放 在 这 个 文件 夹 





Dlock: InnoDB 存 储 引 擎 锁 的 实现 ， 如 S$ 锁 、X 锁 ， 以 及 定义 锁 的 


一 系列 算法 。 


Dlog: 日 志 绥 冲 和 重组 日 志文 件 的 实现 。 对 重组 日 志 感 兴趣 的 应 


该 好 好 阅读 该 源 代码 。 


Dmem: 辅助 缓冲 池 的 实现 ， 用 来 申请 一 些 数据 结构 的 内 存 。 
Dmtr: 事务 的 确 层 实现 。 

Qos: 封装 一 些 对 于 操作 系统 的 操作 。 

Dpage: 页 的 实现 。 

Drow: 对 于 各 种 类 型 行 数据 的 操作 。 


Dsrv: 对 于 InnoDB 存 储 引 擎 参数 的 设计 。 
Dsync: InnoDB 存 储 引 擎 互 斥 量 〈Mutex) 的 实现 。 
Dthr: InnoDB 储 存 引擎 封装 的 可 移植 的 线程 库 。 
Qux: 事务 的 实现 。 


Dut: 工具 类 。 





10.3 MySQL 5.1 版 本 编译 和 调试 InnoDB 源 代码 
10.3.1 Windows 下 的 调试 

在 Windows 平 台 下 ， 可 以 通过 Visual Studion 2003、2005 和 2008 开 发 
工具 对 MySQL 的 源 代码 进行 编译 和 调试 。 在 此 之 前 ， 用 户 需 要 预先 安 
装 如 下 的 工具 。 


DCMake: 可 以 从 http://www.cmake.org 下 载 。 








Dbison: 可 以 从 http://gnuwin32.sourceforge.net/packages/bison.htm 下 
Ro 


安装 之 后 还 需要 通过 configure.js 这 个 命令 进行 配置 : 





C:\workdir>win\configure.js options 





options 比 较 重要 的 选项 如 下 : 


口 WITH INNOBASE STORAGE ENGINE， 支 持 InnoDB 存 储 引 


ž 


QWITH_PARTITION_STORAGE_ENGINE, 分 区 支持 。 
DWITH ARCHIVE STORAGE ENGINE， 支 持 Archive 存 储 引 擎 。 


口 WITH BLACKHOLE STORAGE _ ENGINE， 支 持 Blackhole 存 储 
引擎 。 


DWITH_EXAMPLFE_STORAGE_ENGINE， 支 持 Example 存 储 引 
擎 ， 这 个 存储 引擎 是 展示 给 开发 人 员 的 ， 用 户 可 以 从 这 个 存储 引擎 开始 
构建 自己 的 存储 引擎 。 


DWITH FEDERATED STORAGE ENGINE， 支 持 Federated 存 储 
引擎 。 





DWITH NDBCLUSTER STORAGE _ ENGINE， 支 持 NDB Cluster 


存储 引擎 。 


如 果 我 们 只 是 比较 关心 InnoDB 存 储 引 擎 ， 可 以 这 样 进行 设置 ， 如 
图 10-8 所 示 。 





E C\Windows\system32\cmdexe 


D: Vroject \nysql-d.0.07AJ win \conf igure js WITHINNOBASE STORAGE, ENGINE MYSQL_SERVER_SUPPIA=-dayid 


Ds ro ject \nysql-5.5.5-nd) 














图 10-8 configure.js 配 置 


之 后 可 以 根据 用 户 使 用 的 是 Visual Studio 2005 还 是 Visual Studio 
2008 在 win 文 件 下 运行 build-vsx.bat 文 件 来 生成 Visual Studio 的 工程 文 
件 。build-vs8.bat 表 示 Visual Studio 2005, build-vs8 x64.bat 表 示 需 要 编 
译 64 位 的 MySQL 数 据 库 。 例 如 ， 我 们 需要 在 32 位 的 操作 系统 下 使 用 
Visual Studio 2008 进 行 调 试 工 作 ， 可 以 使 用 如 下 命令 : 





D:\Project\mysql-5.5.5-m3>win\build-vs9.bat 

--Check for working C compiler:C:/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl.exe 
--Check for working C compiler:C:/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl.exe--works 
--Detecting C compiler ABI info 

--Detecting C compiler ABI info-done 

--Check for working CXX compiler:C:/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl.exe 
--Check for working CXX compiler:C:/Program Files/Microsoft Visual Studio 9.0/VC/bin/cl.exe--works 
--Detecting CXX compiler ABI info 

--Detecting CXX compiler ABI info-done 

--Check size of void* 

--Check size of void*-done 

SIZEOF VOIDP-4 

--Looking for include files HAVE CXXABI H 

--Looking for include files HAVE CXXABI H-not found. 

--Looking for include files HAVE NDIR H 

--Looking for include files HAVE NDIR H-not found. 

--Looking for include files HAVE SYS NDIR H 

--Looking for include files HAVE SYS NDIR H-not found. 


--Looking for include files HAVE ASM TERMBITS H 

--Looking for include files HAVE ASM TERMBITS H-not found. 
--Looking for include files HAVE TERMBITS H 

--Looking for include files HAVE TERMBITS H-not found. 
--Looking for include files HAVE VIS H 

--Looking for include files HAVE VIS H-not found. 

--Looking for include files HAVE WCHAR H 

--Looking for include files HAVE WCHAR H-found 

--Looking for include files HAVE WCTYPE H 

--Looking for include files HAVE WCTYPE H-found 

--Looking for include files HAVE XFS XFS H 

--Looking for include files HAVE XFS XFS H-not found. 
--Looking for include files CMAKE HAVE PTHREAD H 

--Looking for include files CMAKE HAVE PTHREAD H-not found. 
--Found Threads: TRUE 

--Looking for pthread rwlockattr setkind np 

--Looking for pthread rwlockattr setkind np-not found 
--Performing Test HAVE SOCKADDR IN SIN LEN 

--Performing Test HAVE SOCKADDR IN SIN LEN-Failed 
--Performing Test HAVE SOCKADDR IN6 SIN6 LEN 

--Performing Test HAVE SOCKADDR IN6 SIN6 LEN-Failed 
--Cannot find wix 3,installer project will not be generated 
--Configuring done 

--Generating done 

--Build files have been written to:D:/Project/mysql-5.5.5-m3 








这 样 就 生成 了 MySQL.sln 的 工程 文件 ， 打 开 这 个 工程 文件 并 将 
mysqld 这 个 项 目 设置 为 默认 的 启动 项 就 可 以 进行 MySQL 的 编译 和 调试 
Ta 


之 后 的 编译 ， 上 断 点 的 设置 和 调试 与 在 Visual Studio 下 操作 一 般 的 程 
序 没 有 什么 区 别 ， 图 10-9 演 示 了 对 InnoDB 存 储 引 擎 的 master thread 进行 
调试 。 
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图 10-9 调试 master thread 


10.3. Linux FI US TA 


Linux 下 的 调试 通常 使 用 Eclipse。 对 于 其 他 类 UNIX 的 操作 系统 ， 如 
Solaris、FreeBSD、MAC 同 样 可 以 使 用 Eclipse 进行 调试 。 首 先 到 
http:Wwww.eclipse.org/downloads/ 下 载 并 安装 Eclipse IDE for 
C/C++Developers。 然 后 ， 解 压 MySQL 源 代码 到 指定 目录 ， 如 解压 
到 /root/workspace/mysql-5.5.5-m3， 接 着 运行 如 下 命令 产生 Make 文 件 ， 
Eclipse 会 使 用 产生 的 这 些 Make 文 件 : 








[root@xen-server mysql-5.5.5-m3]4BUILD/compile-amd64-debug-max-no-ndb-c 





BUILD 下 有 很 多 compile 文 件 ， 用 户 可 以 从 中 选择 所 需要 的 文件 。 
本 书 编译 的 平台 是 64 位 的 Linux 系 统 ， 并 且 我 希望 可 以 进行 Debug， 因 此 
选择 了 compile-amd64-debug-max-no-ndb 文 件 。 注 意 -c 选 项 ， 这 个 选项 只 
生产 Make 文 件 ， 不 进行 编译 。 


接着 打开 Eclipse， 新 建 一 个 C++ 的 项 目 ， 如 图 10-10 所 示 。 


New Project 
Select a wizard 


Create a new C++ project 


Wizards: 

type filter text 

P (General 

v È CCH 
C Project 
B C+ Project 














图 10-10 新 建 一 个 C++ 项 目 


为 项 目 取 个 名 字 ， 如 这 里 的 项 目 名 为 mysql.5 5 5， 并 选择 一 个 空 
的 项 目 ， 如 图 10-11 所 示 。 


CHF Project 
C++ Project 


Create C++ project of selected type 


Project name: mysql 5 5 5 
Use default location 


Location: | froot/workspace/mysql 5 5 5 | | Browse 





Project type: Toolchains: 
Empty Project 
6 Hello World C++ Project 
b C» Shared Library 
b (s Static Library 
b © Makefile project 











Show project types and toolchains only if they are supported on the platform 








图 10-11 选择 空 项 目 


选择 Finish 按 钮 后 ， 可 以 看 到 新 产生 的 一 个 空 项 目 ， 如 图 10-12 所 
示 。 
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Nothing to build for project nysql 5 5 5 
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图 10-312 新 建 的 C++ 项 目 


之 后 选择 左边 的 Project Explorer, Jfi:tiJHmysql 5 5 5， 选 择 新 建 
文件 来， 将 文件 夹 /root/workspace/mysql-5.5.5-m3 导 入 到 工程 ， 如 图 10- 
13 所 示 。 





New Folder 


Folder 
Create a new folder resource. 7 


Enter or select the parent folder: 








Folder name: |mysqi-5.5.5-m3 


Link to folder in the file system 


/root/workspace/mysq|-5.5.5-m3 








图 10-313 选择 文件 夹 


导入 文件 夹 后 再 右 击 项 目 名 mysql_ 5_5_5， 选 择 项 目 属性 ， 在 
C/C++Build 选 项 这 里 进行 设置 ， 需 要 将 Build directory 选 择 为 源 代 码 所 在 
路 径 ， 如 图 10-14 所 示 。 














Resource 


Builders 

' C/C++ Build 

) C/C++ General 
Project References 
Refactoring History 
Run/Debug Settings 

Task Repository 
Wikifext 


Properties for mysql 5 5 5 


(ICH Bul ety 


Configuration: | Debug [ Active ] JN 


= Bulder Settings |Ê Behaviour 





Builder 





Mee bem O 
Use default build command 

Mügmmn ii 
Makefile generation 


C) Generate Makefiles automaticaly — V Expand En e Refs etes 


Build location 


Build directory: |$ {workspace loc:/mysql 5 5 Simysql-5.5.5-m3} 
File system... | Variables... 
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图 10-314 编译 配置 
编译 配置 完 后 ， 程 序 就 会 自动 开始 执行 编译 工作 了 ， 如 图 10-15 所 
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图 10-15 执行 编译 


上 述 的 这 个 过 程 只 是 编译 的 过 程 ， 换 句 话 说， 编译 完 后 就 产生 了 
mysqld 这 样 的 执行 文件 。 如 果 想 要 进行 调试 ， 我 们 还 需要 在 Debug 这 里 
进行 如 下 的 配置 ， 如 图 10-16 所 示 。 











Debug Configurations 


Create, manage, and run configurations 
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Project 
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b Launch Group 
CC Application: 
mysql5.5.5-ma/sqlmysqid Search Project.. 
Connect process input & output to a terminal 
Using Standard Create Process Launcher - Select Any 
Fiter matched 5 of 5 items 








图 10-16 Debug 配 置 


另外 如 果 需 要 配置 一 些 额 外 的 参数 ， 需 要 切换 到 Arguments 选 项 ， 
如 图 10-17 所 示 。 








Create, manage, and run configurations 


Debug Configurations 





TT 





v [t C/C++ Application 


Gi mysql 5 5 5 Debug 


(6) CIC Attach to Application 


[© C/C++ Postmortem Debugger 
> Launch Group 








Filter matched 5 of 5 items 


Q 





Name: mysql 5 5 5 Debug 


E Main td: 


Program arguments: 


Ey 


1 Environment $ Debugger 5/ Source. (^ Refresh, E Common 





-Userzrogt ^ 
~-datadir=/root/workspace/mysql-5.5.5-m3/win/data 
--Socket=/tmpimysql sock 
--lanquage=/root/workspace/mysq/-5.5.5-m3/sqi/share 











Working directory: 





$ {workspace loc:mysql 5 5 5} 





Use default 




















Using Standard Create Process Launcher - Select. Apply — | — Revert 
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图 1037 调试 参数 


之 后 就 可 以 设置 断 点 ， 进 行 调试 工作 了 ， 这 和 一 般 的 程序 并 没有 什 
么 不 同 ， 如 图 10-18 所 示 。 





Debug - mysqi.5 5 5/mysqi-5,5,5-m3/storage/innobase/sry/srvOsry,c - Eclipse -0X 


file Edt Source Refactor Navigate Search Run Project Window Help 


| à a lø O° Qs bof ir Qv cle * [bong » 


don 2 LUOD EN ABRE RRA * © © (ats ^ regnis it Af Enpressans theirs m ues MEL 





v f Thread [17] (Suspended: Breakpoint hit) E HS” 
3 SIV_Mmaster thread) foot orkspacelmysq:3 5 5-m3istorage/nnobase/SrV/sv A lrontiworkspace/mysq-5 5.5-m3/storage/nnobase/srv/srvOsrv.c (line: 2580] 
E 2 start threadi) 0x0000003129206367 
= 1 clone() Ox00000031286d30ad 
D f Thread [18] (Suspended) 
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mutex_enter(&kernel_mutex); "TT n! 
sivüsrv| 
STV n, threads active|SRV MASTER] +t; Y utümemh 
mutex exit (Gkernel_mitex); H utOuth 
V osüproch 
ye ^ V memümemh 
[* «««« When there is database activity by users, we cycle in this 3] memüpoolh 
+ 
adi V syncüsynch 
sry nain thread op info = ‘reserving kemet mter"; V throch 
buf get. total stat (ablif stat); y eene 
n ios very old = log sys-»n, log ios + buf stat,n pages read WI logOrecvh 
+ buf, stat.n pages written; © uiis 
mitex_enter(Gkernel_mitex) ; Miam 
9] usrüsess.h 
/* Store the user activity counter at the start of this loop */ | Y lockülockh 
old activity count = srv activity count; 
M topurgeh 
mtex exit(Bkernel mitex); Y ihffihufh 
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mys 5 5 5 Debug [C/C++ Appicaton /rooyworkspace/mysq-55.5-m3/sqlmysgld (10-8-16 ^49) 


Www ser revue he hh ay TUSVWAYET 
InnoDB; Creating foreign key constraint system tables 
InnoDB: Foreign key constraint system tables created 
100816 16:03:20 InnoDB 1.1.1 started; log sequence number 0 
100816 16:03:33 [Note] Event Scheduler: Loaded 0 events 
100816 16:03:33 [Note] /root/workspace/mysql-5,5.5-m3/sql/mysqld: ready for connections, 
Version: '5,5,5-m3-debug' socket; '/tmp/mysql, sock’ port; 3306 Source distribution 




















图 10-18 用 Eclipse 进行 调试 


10.4  cmakeJ7; xXx ERU 4 i InnoDB 4 fii 5| & 


MySQL 数 据 库 从 5.5 版 本 开始 可 以 直接 通过 命令 cmake 生 成 对 应 的 
MySQL 工 程 文件 ， 例 如 在 Mac OSX 操 作 系 统 下 ， 用 户 可 以 直接 通过 下 
列 命 令 产 生 xcode 对 应 的 MySQL 工 程 文件 : 








上 述 命令 在 MySQL 源 人 码 文件 夹 下 创建 了 bld 文 件 夹 ， 接 着 通过 命令 
cmake 产 生 对 应 xcode 的 工程 文件 ， 之 后 在 文件 夹 下 就 能 看 到 工程 文件 
MySQL.xcodeproj， 双 击 该 文件 就 能 对 MySQL 数 据 库 和 InnoDB 存 储 引 擎 
进行 编译 ， 如 图 10-19 所 示 。 
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P MySQLxcodeproj — © srvOsrv.c a 
Running mysqld : ALL_BUILD BI B ] [B | 
RAT Ael hal 


jet 0257 Editor View Organizer 


srv_n_threads_active[SRV_MASTER] ++; 
mutex_exit (&kernel_mutex); 
loop: 
| kkolololoclolelololololollolelelololelolelololelololloloelelelololelololelolelloleloleloolollololloleololeore/ 
/* ---- When there is database activity by users, we cycle in this 
loop */ 
sry main thread op info = "reserving kernel mutex"; 
buf get total, stat(&buf. stat); 
n ios very old = log sys-»n log ios + buf stat.n pages read 
+ buf stat.n pages written; 
mutex enter(&kernel mutex) ; 


/* Store the user activity counter at the start of this loop */ 
old activity count = srv activity count; 


nutex exit(&kernel mutex); 

if (srv force recovery >= SRV FORCE NO BACKGROUND) ( — C. Thread 2: breakpoint 2.1 
goto suspend thread; 

/* ---- We run the following loop approximately once per second 

when there is database activity */ | 

sry last log flush time = time(NULL) ; 


/* Sleep for 1 second on entrying the for loop below the first time, */ 
next itr time = ut tine ns() + 1000; 


far (12 As i «10: i++) 1 





P Q à t| mysald-) M Thread 2) [lO sr. master thread 


a Jfuu 


M 


> [B buf stat (buf pool stat 0 


old activity count = (ulint) 0 
sry activity count = (ulint) 0 
srv force recovery = (ulint) 0 
[3 block-»lock = Invalid Expression 


图 10-19 MacOS X 操 作 系统 下 通过 xcode 对 MySQL 进 行 编译 


总 之 ，cmake 大 大 简化 了 编译 MySQL 数 据 库 的 难度 。 更 多 关于 
cmake 的 参数 及 说 明 可 见 MySQL 官 方 手册 说 明 。 
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MySQL 数 据 库 和 InnoDB 存 储 引 擎 都 是 开源 的 ， 我 们 可 以 通过 常用 
的 开发 工具 ， 如 Visual Studio、Eclipse 对 其 进行 编译 和 调试 ， 以 此 来 更 
好 地 了 解数 据 库 内 部 运行 机 制 。 有 能 力 的 开发 人 员 可 以 进一步 扩展 数据 
库 的 功能 ， 这 就 是 开源 的 魅力 ， 这 在 Oracle、Microsoft SQL Server, 
DB2 等 商业 数据 库 中 是 永远 不 可 能 发 生 的 。 


